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Abstract 
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Objects with their local state, the messages they pass, 

A property, a package, the control point for a catch — 

In the Lambda Order they are all first-class. 

One Thing to name them all, One Thing to define them, 
One Thing to place them in environments and bind them, 
In the Lambda Order they are all first-class. 
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SUMMARY 

The report gives a defining description of the program¬ 
ming language Scheme. Scheme is a statically scoped and 
properly tail-recursive dialect of the Lisp programming 
language invented by Guy Lewis Steele Jr. and Gerald 
Jay Sussman. It was designed to have an exceptionally 
clear and simple semantics and few different ways to form 
expressions. A wide variety of programming paradigms, in¬ 
cluding imperative, functional, and message passing styles, 
find convenient expression in Scheme. 

The introduction offers a brief history of the language and 
of the report. 

The first three chapters present the fundamental ideas of 
the language and describe the notational conventions used 
for describing the language and for writing programs in the 
language. 

Chapters 4 and 5 describe the syntax and semantics of 
expressions, programs, and definitions. 

Chapter 6 describes Scheme’s built-in procedures, which 
include all of the language’s data manipulation and in¬ 
put/output primitives. 

Chapter 7 provides a formal syntax for Scheme written in 
extended BNF, along with a formal denotational semantics. 
An example of the use of the language follows the formal 
syntax and semantics. . 

The appendix describes a macro facility that may be used 
to extend the syntax of Scheme. 

The report concludes with a bibliography and an alpha¬ 
betic index. 
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INTRODUCTION 


Programming languages should be designed not by piling 
feature on top of feature, but by removing the weaknesses 
and restrictions that make additional features appear nec¬ 
essary. Scheme demonstrates that a very small number of 
rules for forming expressions, with no restrictions on how 
they are composed, suffice to form a practical and efficient 
programming language that is flexible enough to support 
most of the major programming paradigms in use today. 

Scheme was one of the first programming languages to in¬ 
corporate first class procedures as in the lambda calculus, 
thereby proving the usefulness of static scope rules and 
block structure in a dynamically typed language. Scheme 
was the first major dialect of Lisp to distinguish procedures 
from lambda expressions and symbols, to use a single lex¬ 
ical environment for all variables, and to evaluate the op¬ 
erator position of a procedure call in the same way as an 
operand position. By relying entirely on procedure calls 
to express iteration, Scheme emphasized the fact that tail- 
recursive procedure calls are essentially goto’s that pass ar¬ 
guments. Scheme was the first widely used programming 
language to embrace first class escape procedures, from 
which all previously known sequential control structures 
can be synthesized. More recently, building upon the de¬ 
sign of generic arithmetic in Common Lisp, Scheme intro¬ 
duced the concept of exact and inexact numbers. With the 
appendix to this report Scheme becomes the first program¬ 
ming language to support hygienic macros, which permit 
the syntax of a block-structured language to be extended 
reliably. 

Background 

The first description of Scheme was written in 1975 [91]. A 
revised report [85] appeared in 1978, which described the 
evolution of the language as its MIT implementation was 
upgraded to support an innovative compiler [80]. Three 
distinct projects began in 1981 and 1982 to use variants 
of Scheme for courses at MIT, Yale, and Indiana Univer¬ 
sity [66, 57, 34], An introductory computer science text¬ 
book using Scheme was published in 1984 [2]. 

As Scheme became more widespread, local dialects be¬ 
gan to diverge until students and researchers occasion¬ 
ally found it difficult to understand code written at other 
sites. Fifteen representatives of the major implementations 
of Scheme therefore met in October 1984 to work toward 
a better and more widely accepted standard for Scheme. 
Their report [8] was published at MIT and Indiana Uni¬ 
versity in the summer of 1985. Another round of revision 
took place in the spring of 1986 [68]. The present report 
reflects further revisions agreed upon in a meeting that pre¬ 
ceded the 1988 ACM Conference on Lisp and Functional 
Programming and in subsequent electronic mail. 


We intend this report to belong to the entire Scheme com¬ 
munity, and so we grant permission to copy it in whole or in 
part without fee. In particular, we encourage implementors 
of Scheme to use this report as a starting point for manuals 
and other documentation, modifying it as necessary. 
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1. Overview of Scheme 
1.1. Semantics 

This section gives an overview of Scheme’s semantics. A 
detailed informal semantics is the subject of chapters 3 
through 6. For reference purposes, section 7.2 provides a 
formal semantics of Scheme. 

Following Algol, Scheme is a statically scoped program¬ 
ming language. Each use of a variable is associated with a 
lexically apparent binding of that variable. 

Scheme has latent as opposed to manifest types. Types 
are associated with values (also called objects) rather than 
with variables. (Some authors refer to languages with 
latent types as weakly typed or dynamically typed lan¬ 
guages.) Other languages with latent types are APL, 
Snobol, and other dialects of Lisp. Languages with mani¬ 
fest types (sometimes referred to as strongly typed or stat¬ 
ically typed languages) include Algol 60, Pascal, and C. 

All objects created in the course of a Scheme computation, 
including procedures and continuations, have unlimited ex¬ 
tent. No Scheme object is ever destroyed. The reason that 
implementations of Scheme do not (usually!) run out of 
storage is that they are permitted to reclaim the storage 
occupied by an object if they can prove that the object 
cannot possibly matter to any future computation. Other 
languages in which most objects have unlimited extent in¬ 
clude APL and other Lisp dialects. 

Implementations of Scheme are required to be properly 
tail-recursive. This allows the execution of an iterative 
computation in constant space, even if the iterative compu¬ 
tation is described by a syntactically recursive procedure. 
Thus with a tail-recursive implementation, iteration can be 
expressed using the ordinary procedure-call mechanics, so 
that special iteration constructs are useful only as syntactic 
sugar. 

Scheme procedures are objects in their own right. Pro¬ 
cedures can be created dynamically, stored in data struc¬ 
tures, returned as results of procedures, and so on. Other 
languages with these properties include Common Lisp and 
ML. 

One distinguishing feature of Scheme is that continuations, 
which in most other languages only operate behind the 
scenes, also have “first-class” status. Continuations are 
useful for implementing a wide variety of advanced control 
constructs, including non-local exits, backtracking, and 
coroutines. See section 6.9. 

Arguments to Scheme procedures are always passed by 
value, which means that the actual argument expressions 
are evaluated before the procedure gains control, whether 
the procedure needs the result of the evaluation or not. 


ML, C, and APL are three other languages that always 
pass arguments by value. This is distinct from the lazy- 
evaluation semantics of Haskell, or the call-by-name se¬ 
mantics of Algol 60, where an argument expression is not 
evaluated unless its value is needed by the procedure. 

Scheme’s model of arithmetic is designed to remain as in¬ 
dependent as possible of the particular ways in which num¬ 
bers are represented within a computer. In Scheme, every 
integer is a rational number, every rational is a real, and 
every real is a complex number. Thus the distinction be¬ 
tween integer and real arithmetic, so important to many 
programming languages, does not appear in Scheme. In its 
place is a distinction between exact arithmetic, which cor¬ 
responds to the mathematical ideal, and inexact arithmetic 
on approximations. As in Common Lisp, exact arithmetic 
is not limited to integers. 

1.2. Syntax 

Scheme, like most dialects of Lisp, employs a fully paren¬ 
thesized prefix notation for programs and (other) data; the 
grammar of Scheme generates a sublanguage of the lan¬ 
guage used for data. An important consequence of this sim¬ 
ple, uniform representation is the susceptibility of Scheme 
programs and data to uniform treatment by other Scheme 
programs. 

The read procedure performs syntactic as well a.s lexical 
decomposition of the data it reads. The read procedure 
parses its input as data (section 7.1.2), not as program. 

The formal syntax of Scheme is described in section 7.1. 

1.3. Notation and terminology 

1.3.1. Essential and non-essential features 

It is required that every implementation of Scheme support 
features that are marked as being essential. Features not 
explicitly marked as essential are not essential. Implemen¬ 
tations are free to omit non-essential features of Scheme 
or to add extensions, provided the extensions are not in 
conflict with the language reported here. In particular, 
implementations must support portable code by provid¬ 
ing a syntactic mode that preempts no lexical conventions 
of this report and reserves no identifiers other than those 
listed as syntactic keywords in section 2.1. 

1.3.2. Error situations and unspecified behavior 

When speaking of an error situation, this report uses the 
phrase “an error is signalled” to indicate that implemen¬ 
tations must detect and report the error. If such wording 
does not appear in the discussion of an error, then imple¬ 
mentations are not. required to detect or report the error, 
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though they are encouraged to do so. An error situation 
that implementations are not required to detect is usually 
referred to simply as “an error.” 

For example, it is an error for a procedure to be passed an 
argument that the procedure is not explicitly specified to 
handle, even though such domain errors are seldom men¬ 
tioned in this report. Implementations may extend a pro¬ 
cedure’s domain of definition to include such arguments. 

This report uses the phrase “may report a violation of an 
implementation restriction” to indicate circumstances un¬ 
der which an implementation is permitted to report that 
it is unable to continue execution of a correct program be¬ 
cause of some restriction imposed by the implementation. 
Implementation restrictions are of course discouraged, but 
implementations are encouraged to report violations of im¬ 
plementation restrictions. 

For example, an implementation may report a violation of 
an implementation restriction if it does not have enough 
storage to run a program. 

If the value of an expression is said to be “unspecified,” 
then the expression must evaluate to some object without 
signalling an error, but the value depends on the imple¬ 
mentation; this report explicitly does not say what value 
should be returned. 

1.3.3. Entry format 

Chapters 4 and 6 are organized into entries. Each entry de¬ 
scribes one language feature or a group of related features, 
where a feature is either a syntactic construct or a built-in 
procedure. An entry begins with one or more header lines 
of the form 

template essential category 


procedure. Argument names in the template are italicized. 
Thus the header line 


(vector-ref vector k ) essential procedure 

indicates that the essential built-in procedure vector-ref 
takes two arguments, a vector vector and an exact non¬ 
negative integer k (see below). The header lines 

(make-vector k) essential procedure 

(make-vector k fill) procedure 

indicate that in all implementations, the make-vector pro¬ 
cedure must be defined to take one argument, and some 
implementations will extend it to take two arguments. 


It is an error for an operation to be presented with an ar¬ 
gument that it is not specified to handle. For succinctness, 
we follow the convention that if an argument name is also 
the name of a type listed in section 3.4, then that argu¬ 
ment must be of the named type. For example, the header 
line for vector-ref given above dictates that the first ar¬ 
gument to vector-ref must be a vector. The following 
naming conventions also imply type restrictions: 


obj 
list, 


list i, ... list 


2l, . 

Xi, 

Vu ■ 
<lu ■ 
ni, 
k i, 


> ■ 

• Xj, 

■ Vj, ■ 
1j > ' 

■ nj; 

■ kj. . 


any object 

3 , ... list (see section 6.3) 
complex number 
real number 
real number 
rational number 
integer 

exact non-negative integer 


1.3.4. Evaluation examples 

The symbol “==>■” used in program examples should be 
read “evaluates to.” For example, 

(* 5 8 ) =$• 40 


if the feature is an essential feature, or simply 

template category 

if the feature is not an essential feature. 

If category is “syntax”, the entry describes an expression 
type, and the header line gives the syntax of the expression 
type. Components.of expressions are designated by syn¬ 
tactic variables, which are written using angle brackets, 
for example, (expression), (variable). Syntactic variables 
should be understood to denote segments of program text; 
for example, (expression) stands for any string of charac¬ 
ters which is a syntactically valid expression. The notation 

(thingi) ... 

indicates zero or more occurrences of a (thing), and 
(thingi) (things) ... 

indicates one or more occurrences of a (thing). 

If category is “procedure”, then the entry describes a pro¬ 
cedure, and the header line gives a template for a call to the 


means that the expression (+5 8) evaluates to the ob¬ 
ject 40. Or, more precisely: the expression given by the 
sequence of characters “(* 5 8)” evaluates, in the initial 
environment, to an object that may be represented exter¬ 
nally by the sequence of characters “40”. See section 3.3 
for a discussion of external representations of objects. 

1.3.5. Naming conventions 

By convention, the names of procedures that always return 
a boolean value usually end in “?”. Such procedures are 
called predicates. 

By convention, the names of procedures that store values 
into previously allocated locations (see section 3.5) usually 
end in “!”. Such procedures are called mutation proce¬ 
dures. By convention, the value returned by a mutation 
procedure is unspecified. 

By convention, “->” appears within the names of proce¬ 
dures that take an object of one type and return an anal¬ 
ogous object of another type. For example, list->vector 
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takes a list and returns a vector whose elements are the 
same as those of the list. 

2. Lexical conventions 

This section gives an informal account of some of the lexical 
conventions used in writing Scheme programs. For a formal 
syntax of Scheme, see section 7.1. 

Upper and lower case forms of a letter are never distin¬ 
guished except within character and string constants. For 
example, Foo is the same identifier as F00, and #xiAB is 
the same number as #Xlab. 

2.1. Identifiers 

Most identifiers allowed by other programming languages 
are also acceptable to Scheme. The precise rules for form¬ 
ing identifiers vary among implementations of Scheme, but 
in all implementations a sequence of letters, digits, and “ex¬ 
tended alphabetic characters” that begins with a character 
that cannot begin a number is an identifier. In addition, 
+ , -, and . . . are identifiers. Here are some examples of 
identifiers: 

lambda q 

list->vector soup 

+ V17a 

<=? a343cTMNs 

the-word-recursion-has-many-meanings 

Extended alphabetic characters may be used within iden¬ 
tifiers as if they were letters. The following are extended 
alphabetic characters: 

See section 7.1.1 for a formal syntax of identifiers. 
Identifiers have several uses within Scheme programs: 

• Certain identifiers are reserved for use as syntactic 
keywords (see below). 

• Any identifier that is not a syntactic keyword may be 
used as a variable (see section 3.1). 

• When an identifier appears as a literal or within a 
literal (see section 4.1.2), it is being used to denote a 
symbol (see section 6.4). 

The following identifiers are syntactic keywords, and 
should not be used as variables: 


=> 

do 

or 

and 

else 

quasiquote 

begin 

if 

quote 

case 

lambda 

set! 

cond 

let 

unquote 

define 

let* 

unquote-splicing 

delay 

letrec 



Some implementations allow all identifiers, including syn¬ 
tactic keywords, to be used as variables. This is a com¬ 
patible extension to the language, but ambiguities in the 
language result when the restriction is relaxed, and the 
ways in which these ambiguities are resolved vary between 
implementations. 

2.2. Whitespace and comments 

Whitespace characters are spaces and newlines. (Imple¬ 
mentations typically provide additional whitespace char¬ 
acters such as tab or page break.) Whitespace is used for 
improved readability and as necessary to separate tokens 
from each other, a token being an indivisible lexical unit 
such as an identifier or number, but is otherwise insignifi¬ 
cant. Whitespace may occur between any two tokens, but 
not within a token. Whitespace may also occur inside a 
string, where it is significant. 

A semicolon (;) indicates the start of a comment. The 
comment continues to the end of the line on which the 
semicolon appears. Comments are invisible to Scheme, but 
the end of the line is visible as whitespace. This prevents a 
comment from appearing in the middle of an identifier or 
number. 

;;; The FACT procedure computes the factorial 
;;; of a non-negative integer. 

(define fact 
(lambda (n) 

(if (= n 0) 

1 ;Base case: return 1 

(* n (fact (- n 1)))))) 

2.3. Other notations 

For a description of the notations used for numbers, see 
section 6.5. 

. + - These are used in numbers, and may also occur any¬ 
where in an identifier except as the first character. A 
delimited plus or minus sign by itself is also an identi¬ 
fier. A delimited period (not occurring within a num¬ 
ber or identifier) is used in the notation for pairs (sec¬ 
tion 6.3), and to indicate a rest-parameter in a formal 
parameter list (section 4.1.4). A delimited sequence of 
three successive periods is also an identifier. 

( ) Parentheses are used for grouping and to notate lists 
(section 6.3). 

’ The single quote character is used to indicate literal data 
(section 4.1.2). 

' The backquote character is used to indicate almost- 
constant data (section 4.2.6). 

, , <5 The character comma and the sequence comma at- 
sign are used in conjunction with backquote (sec¬ 
tion 4.2.6). 
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" The double quote character is used to delimit strings 
(section 6.7). 

\ Backslash is used in the syntax for character constants 
(section 6.6) and as an escape character within string 
constants (section 6.7). 

[ ] { } Left and right square brackets and curly braces 
are reserved for possible future extensions to the lan¬ 
guage. 

# Sharp sign is used for a variety of purposes depending 
on the character that immediately follows it: 

#t #f These are the boolean constants (section 6.1). 

#\ This introduces a character constant (section 6.6). 

#( This introduces a vector constant (section 6.8). Vector 
constants are terminated by ) . 

#e #i #b #o #d #x These are used in the notation for 
numbers (section 6.5.4). 

3. Basic concepts 

3.1. Variables and regions 

Any identifier that is not a syntactic keyword (see sec¬ 
tion 2.1) may be used as a variable. A variable may name 
a location where a value can be stored. A variable that does 
so is said to be bound to the location. The set of all visible 
bindings in effect at some point in a program is known as 
the environment in effect at that point. The value stored 
in the location to which a variable is bound is called the 
variable’s value. By abuse of terminology, the variable is 
sometimes said to name the value or to be bound to the 
value. This is not quite accurate, but confusion rarely re¬ 
sults from this practice. 

Certain expression types are used to create new locations 
and to bind variables to those locations. The most funda¬ 
mental of these binding constructs is the lambda expres¬ 
sion, because all other binding constructs can be explained 
in terms of lambda expressions. The other binding con¬ 
structs are let, let*, letrec, and do expressions (see sec¬ 
tions 4.1.4, 4.2.2, and 4.2.4). • - 

Like Algol and Pascal, and unlike most other dialects of 
Lisp except for Common Lisp, Scheme is a statically scoped 
language with block structure. To each place where a vari¬ 
able is bound in a program there corresponds a region of the 
program text within which the binding is effective. The re¬ 
gion is determined by the particular binding construct that 
establishes the binding; if the binding is established by a 
lambda expression, for example, then its region is the en¬ 
tire lambda expression. Every reference to or assignment 
of a variable refers to the binding of the variable that es¬ 
tablished the innermost of the regions containing the use. 


If there is no binding of the variable whose region contains 
the use, then the use refers to the binding for the variable 
in the top level environment, if any (section 6); if there is 
no binding for the identifier, it is said to be unbound. 

3.2. True and false 

Any Scheme value can be used as a boolean value for the 
purpose of a conditional test. As explained in section 6.1, 
all values count as true in such a test except for #f. This 
report uses the word “true” to refer to any Scheme value 
that counts as true, and the word “false” to refer to #f. 

Note: In some implementations the empty list also counts as 
false instead of true. 

3.3. External representations 

An important concept in Scheme (and Lisp) is that of the 
external representation of an object as a sequence of char¬ 
acters. For example, an external representation of the inte¬ 
ger 28 is the sequence of characters “28”, and an external 
representation of a list consisting of the integers 8 and 13 
is the sequence of characters “(8 13)”. 

The external representation of an object is not neces¬ 
sarily unique. The integer 28 also has representations 
“#e28.000” and “#xlc”, and the list in the previous para¬ 
graph also has the representations “( 08 13 )” and “(8 
. (13 . ()))” (see section 6.3). 

Many objects have standard external representations, but 
some, such as procedures, do not have standard represen¬ 
tations (although particular implementations may define 
representations for them). 

An external representation may be written in a program to 
obtain the corresponding object (see quote, section 4.1.2). 

External representations can also be used for input and 
output. The procedure read (section 6.10.2) parses ex¬ 
ternal representations, and the procedure write (sec¬ 
tion 6.10.3) generates them. Together, they provide an 
elegant and powerful input/output facility. 

Note that the sequence of characters “(+ 2 6)” is not an 
external representation of the integer 8, even though it is an 
expression evaluating to the integer 8; rather, it is an exter¬ 
nal representation of a three-element list, the elements of 
which are the symbol + and the integers 2 and 6. Scheme’s 
syntax has the property that any sequence of characters 
that is an expression is also the external representation of 
some object. This can lead to confusion, since it may not 
be obvious out of context whether a given sequence of char¬ 
acters is intended to denote data or program, but it is also 
a source of power, since it facilitates writing programs such 
as interpreters and compilers that treat programs as data 
(or vice versa). 
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The syntax of external representations of various kinds of 
objects accompanies the description of the primitives for 
manipulating the objects in the appropriate sections of 
chapter 6. 

3.4. Disjointness of types 

No object satisfies more than one of the following predi¬ 
cates: 

boolean? pair? 

symbol? number? 

char? string? 

vector? procedure? 

These predicates define the types boolean, pair, symbol, 
number, char (or character), string, vector, and procedure. 

3.5. Storage model 

Variables and objects such as pairs, vectors, and strings 
implicitly denote locations or sequences of locations. A 
string, for example, denotes as many locations as there 
are characters in the string. (These locations need not 
correspond to a full machine word.) A new value may be 
stored into one of these locations using the string-set! 
procedure, but the string continues to denote the same 
locations as before. 

An object fetched from a location, by a variable reference or 
by a procedure such as car, vector-ref, or string-ref, 
is equivalent in the sense of eqv? (section 6.2) to the object 
last stored in the location before the fetch. 

Every location is marked to show whether it is in use. No 
variable or object ever refers to a location that is not in use. 
Whenever this report speaks of storage being allocated for 
a variable or object, what is meant is that an appropriate 
number of locations are chosen from the set of locations 
that are not in use, and the chosen locations are marked 
to indicate that they are now in use before the variable or 
object is made to denote them. 

In many systems it is desirable for constants (i.e. the val¬ 
ues of literal expressions) to reside in read-only-memory. 
To express this, it is convenient to imagine that every ob¬ 
ject that denotes locations is associated with a flag telling 
whether that object is mutable or immutable. The con¬ 
stants and the strings returned by symbol->string are 
then the immutable objects, while all objects created by 
the other procedures listed in this report are mutable. It 
is an error to attempt to store a new value into a location 
that is denoted by an immutable object. 

4. Expressions 

A Scheme expression is a construct that returns a value, 
such as a variable reference, literal, procedure call, or con¬ 
ditional. 


Expression types are categorized as primitive or derived. 
Primitive expression types include variables and procedure 
calls. Derived expression types are not semantically primi¬ 
tive, but can instead be explained in terms of the primitive 
constructs as in section 7.3. They are redundant in the 
strict sense of the word, but they capture common pat¬ 
terns of usage, and are therefore provided as convenient 
abbreviations. 

4.1. Primitive expression types 

4.1.1. Variable references 

(variable) essential syntax 

An expression consisting of a variable (section 3.1) is a 
variable reference. The value of the variable reference is 
the value stored in the location to which the variable is 
bound. It is an error to reference an unbound variable. 

(define x 28) 

x ==$- 28 

4.1.2. Literal expressions 

(quote (datum)) essential syntax 

’ (datum) essential syntax 

(constant) essential syntax 

(quote (datum)) evaluates to (datum). (Datum) may be 
any external representation of a Scheme object (see sec¬ 
tion 3.3). This notation is used to include literal constants 
in Scheme code. 

(quote a) =>• a 

(quote #(a b c)) #(a b c) 

(quote (+ 1 2)) =>■ (+ 1 2) 

(quote (datum)) maybe abbreviated as ’(datum). The 
two notations are equivalent in all respects. 

’ a 

’#(a b c) 

’() 

’(+ 12 ) 

’(quote a) 

’ ’a 

Numerical constants, string constants, character constants, 
and boolean constants evaluate “to themselves”; they need 
not be quoted. 

’ "abc" =* "abc" 

"abc" ==> "abc" 

’145932 =* 145932 

145932 =*• 145932 

>#t =? #t 

#t =? #t 

As noted in section 3.5, it is an error to alter a constant 
(i.e. the value of a literal expression) using a mutation pro¬ 
cedure like set-car! or string-set!. 
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4.1.3. Procedure calls 

((operator) (operand].) ...) essential syntax 

A procedure call is written by simply enclosing in parenthe¬ 
ses expressions for the procedure to be called and the argu¬ 
ments to be passed to it. The operator and operand expres¬ 
sions are evaluated (in an unspecified order) and the result¬ 
ing procedure is passed the resulting arguments. 

(+3 4) 7 

((if #f + *) 3 4) =4- 12 

A number of procedures are available as the values of vari¬ 
ables in the initial environment; for example, the addition 
and multiplication procedures in the above examples are 
the values of the variables + and *. New procedures are cre¬ 
ated by evaluating lambda expressions (see section 4.1.4). 

Procedure calls are also called combinations. 

Note: In contrast to other dialects of Lisp, the order of 

evaluation is unspecified, and the operator expression and the 
operand expressions are always evaluated with the same evalu¬ 
ation rules. 

Note: Although the order of evaluation is otherwise unspeci¬ 
fied, the effect of any concurrent evaluation of the operator and 
operand expressions is constrained to be consistent with some 
sequential order of evaluation. The order of evaluation may be 
chosen differently for each procedure call. 

Note: In many dialects of Lisp, the empty combination, 0, 
is a legitimate expression. In Scheme, combinations must have 
at least one subexpression, so () is not a syntactically valid 
expression. 

4.1.4. Lambda expressions 

(lambda (formals) (body)) essential syntax 

Syntax: (Formals) should be a formal arguments list as 
described below, and (body) should be a sequence of one 
or more expressions. 

Semantics: A lambda expression evaluates to a procedure. 
The environment in effect when the lambda expression was 
evaluated is remembered as part of the procedure. When 
the procedure is later called with some actual arguments, 
the environment in which the lambda expression was evalu¬ 
ated will be extended by binding the variables in the formal 
argument list to fresh locations, the corresponding actual 
argument values will be stored in those locations, and the 
expressions in the body of the lambda expression will be 
evaluated sequentially in the extended environment. The 
result of the last expression in the body will be returned 
as the result of the procedure call. 

(lambda (x) (+ x x)) => a procedure 

((lambda (x) (+ x x)) 4) => 8 

(define reverse-subtract 


(lambda (x y) (- y x))) 

(reverse-subtract 7 10) => 3 

(define add4 
(let ((x 4)) 

(lambda (y) (+ x y)>)) 

(add4 6) => 10 

(Formals) should have one of the following forms: 

♦ ((variablei) ...): The procedure takes a fixed num¬ 
ber of arguments; when the procedure is called, the 
arguments will be stored in the bindings of the corre¬ 
sponding variables. 

♦ (variable): The procedure takes any number of ar¬ 
guments; when the procedure is called, the sequence 
of actual arguments is converted into a newly allo¬ 
cated list, and the list is stored in the binding of the 
(variable). 

♦ ((variable]) ... (variable n _i) . (variable n )): If a 
space-delimited period precedes the last variable, then 
the value stored in the binding of the last variable will 
be a newly allocated list of the actual arguments left 
over after all the other actual arguments have been 
matched up against the other formal arguments. 

It is an error for a (variable) to appear more than once in 
(formals). 

((lambda x x) 3 4 5 6) => (3 4 5 6) 

((lambda (x y . z) z) 

3 4 5 6) =>(56) 

Each procedure created as the result of evaluating a lambda 
expression is tagged with a storage location, in order to 
make eqv? and eq? work on procedures (see section 6.2). 

4.1.5. Conditionals 

(if (test) (consequent) (alternate)) essential syntax 
(if (test) (consequent)) syntax 

Syntax: (Test), (consequent), and (alternate) may be arbi¬ 
trary expressions. 

Semantics: An if expression is evaluated as follows: first, 
(test) is evaluated. If it yields a true value (see section 6.1), 
then (consequent) is evaluated and its value is returned. 
Otherwise (alternate) is evaluated and its value is returned. 
If (test) yields a false value and no (alternate) is specified, 
then the result of the expression is unspecified. 

(if (> 3 2) ’yes ’no) =4- yes 

(if (> 2 3) ’yes ’no) =4- no 

(if (> 3 2) 

(- 3 2) 

(+3 2)) =4- 1 
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4.1.6. Assignments 

(set! (variable) (expression)) essential syntax 

(Expression) is evaluated, and the resulting value is stored 
in the location to which (variable) is bound. (Variable) 
must be bound either in some region enclosing the set! 
expression or at top level. The result of the set! expression 
is unspecified. 

(define x 2) 

(+ x 1) =* 3 

(set! x 4) =>• unspecified 

(+ x 1) => 5 

4.2. Derived expression types 

For reference purposes, section 7.3 gives rewrite rules that 
will convert constructs described in this section into the 
primitive constructs described in the previous section. 

4.2.1. Conditionals 

(cond (clausej) (clause 2 ) ...) essential syntax 

Syntax: Each (clause) should be of the form 
((test) (expression) ...) 

where (test) is any expression. The last (clause) may be 
an “else clause,” which has the form 

(else (expression:) (expression) ...). 

Semantics: A cond expression is evaluated by evaluating 
the (test) expressions of successive (clause) s in order until 
one of them evaluates to a true value (see section 6.1). 
When a (test) evaluates to a true value, then the remaining 
(expression) s in its (clause) are evaluated in order, and the 
result of the last (expression) in the (clause) is returned 
as the result of the entire cond expression. If the selected 
(clause) contains only the (test) and no (expression) s, then 
the value of the (test) is returned as the result. If all (test)s 
evaluate to false values, and there is no else clause, then 
the result of the conditional expression is unspecified; if 
there is an else clause, then its (expression)s are evaluated, 
and the value of the last one is returned. 

(cond ((> 3 2) ’greater) _ 

((< 3 2) ’less)) =£- greater 

(cond ((> 3 3) ’greater) 

((< 3 3) ’less) 

(else ’equal)) => equal 

Some implementations support an alternative (clause) syn¬ 
tax, ((test) => (recipient)), where (recipient) is an expres¬ 
sion. If (test) evaluates to a true value, then (recipient) is 
evaluated. Its value must be a procedure of one argument; 
this procedure is then invoked on the value of the (test). 

(cond ((assv ’b ’((a 1) (b 2))) => cadr) 

(else #f)) 2 


(case (key) (clausei) (clause 2 ) ...) essential syntax 

Syntax: (Key) may be any expression. Each (clause) 
should have the form 

(((datumi) ...) (expressioni) (expressions) ■••), 

where each (datum) is an external representation of some 
object. All the (datum)s must be distinct. The last 
(clause) may be an “else clause,” which has the form 

(else (expressioni) (expression) ...). 

Semantics: A case expression is evaluated as follows. 
(Key) is evaluated and its result is compared against each 
(datum). If the result of evaluating (key) is equivalent 
(in the sense of eqv?; see section 6.2) to a (datum), then 
the expressions in the corresponding (clause) are evaluated 
from left to right and the result of the last expression in 
the (clause) is returned as the result of the case expres¬ 
sion. If the result of evaluating (key) is different from every 
(datum), then if there is an else clause its expressions are 
evaluated and the result of the last is the result of the case 
expression; otherwise the result of the case expression is 
unspecified. 

(case (* 2 3) 

((2357) ’prime) 

((1 4 6 8 9) ’composite)) =>■ composite 
(case (car ’(c d)) 

((a) ’a) 

((b) ’b)) =$- unspecified 

(case (car ’(c d)) 

((a e i o u) ’vowel) 

((w y) ’semivowel) 

(else ’consonant)) =>■ consonant 


(and (testi) .. .) essential syntax 

The (test) expressions are evaluated from left to right, and 
the value of the first expression that evaluates to a false 
value (see section 6.1) is returned. Any remaining expres¬ 
sions are not evaluated. If all the expressions evaluate to 
true values, the value of the last expression is returned. If 
there are no expressions then #t is returned. 


(and (= 22) (> 2 1)) 


#t 

(and (= 2 2) (< 2 D) 

=*> 

#f 

(and 12 ’c ’(f g)) 

=4- 

(f g) 

(and) 

=$■ 



(or (testi) ...) essential syntax 

The (test) expressions are evaluated from left to right, and 
the value of the first expression that evaluates to a true 
value (see section 6.1) is returned. Any remaining expres¬ 
sions are not evaluated. If all expressions evaluate to false 
values, the value of the last expression is returned. If there 
are no expressions then #f is returned. 
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(or 

(» 22) 02 

1)> 


#t 

(or 

(= 2 2) « 2 

D) 


#t 

(or 

#f #f #f) 


=> 

#f 

(or 

(nieinq ’b ’ (a 
(/ 3 0)) 

be)) 


(b c) 


(let ((x 2) (y 3)) 

(let* ((x 7) 

(z (+ x y))) 

(* z x))) ==? 70 


4.2.2. Binding constructs 

The three binding constructs let, let*, and letrec give 
Scheme a block structure, like Algol 60. The syntax of the 
three constructs is identical, but they differ in the regions 
they establish for their variable bindings. In a let ex¬ 
pression, the initial values are computed before any of the 
variables become bound; in a let* expression, the bind¬ 
ings and evaluations are performed sequentially; while in a 
letrec expression, all the bindings are in effect while their 
initial values are being computed, thus allowing mutually 
recursive definitions. 

(let (bindings) (body)) essential syntax 

Syntax: (Bindings) should have the form 
(((variablei) (initi)) ...), 

where each (init) is an expression, and (body) should be a 
sequence of one or more expressions. It is an error for a 
(variable) to appear more than once in the list of variables 
being bound. 

Semantics: The (init)s are evaluated in the current envi¬ 
ronment (in some unspecified order), the (variable)s are 
bound to fresh locations holding the results, the (body) is 
evaluated in the extended environment, and the value of 
the last expression of (body) is returned. Each binding of 
a (variable) has (body) as its region. 


(letrec (bindings) (body)) essential syntax 

Syntax: (Bindings) should have the form 
( ((variablei) (initi)) ...), 

and (body) should be a sequence of one or more expres¬ 
sions. It is an error for a (variable) to appear more than 
once in the list of variables being bound. 

Semantics: The (variable)s are bound to fresh locations 
holding undefined values, the (init)s are evaluated in the 
resulting environment (in some unspecified order), each 
(variable) is assigned to the result of the corresponding 
(init), the (body) is evaluated in the resulting environment, 
and the value of the last expression in (body) is returned. 
Each binding of a (variable) has the entire letrec expres¬ 
sion as its region, making it possible to define mutually 
recursive procedures. 


(letrec ((even? 

(lambda (n) 

(if (zero? n) 

#t 

(odd? (- n 1))))) 

(odd? 

(lambda (n) 

(if (zero? n) 


(even? 88)) 


#f 

(even? (- n 1)))))) 
#t 


(let ((x 2) (y 3)) 

(* x y)) => 6 

(let ((x 2) (y 3)) 

(let ((x 7) 

(z (+ x y))) 

(* z x))) 35 

See also named let, section 4.2.4. 


One restriction on letrec is very important: it must be 
possible to evaluate each (init) without assigning or refer¬ 
ring to the value of any (variable). If this restriction is 
violated, then it is an error. The restriction is necessary 
because Scheme passes arguments by value rather than by 
name. In the most common uses of letrec, all the (init)s 
are lambda expressions and the restriction is satisfied au¬ 
tomatically. 


(let* (bindings) (body)) syntax 

Syntax: (Bindings) should have the form 
( ((variablei) (initi)) ... ), 

and (body) should be a sequence of one or more expres¬ 
sions. 

Semantics: Let* is similar to let, but the bindings are 
performed sequentially from left to right, and the region of 
a binding indicated by ((variable) (init)) is that part of 
the let* expression to the right of the binding. Thus the 
second binding is done in an environment in which the first 
binding is visible, and so on. 


4.2.3. Sequencing 

(begin (expressioni) (expression) ...) essential syntax 

The (expression)s are evaluated sequentially from left to 
right, and the value of the last (expression) is returned. 
This expression type is used to sequence side effects such 
as input and output. 

(define x 0) 

(begin (set! x 5) 

(+ x D) =4-6 
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(begin (display "4 plus 1 equals ") 

(display (+ 4 1))) ==>• unspecified 

and prints 4 plus i equals 5 

Note: [2] uses the keyword sequence instead of begin. 

4.2.4. Iteration 

(do (({variablei} (initi) (stepi)) syntax 

...) 

((test) (expression) ...) 

(command) ...) 

Do is an iteration construct. It specifies a set of variables 
to be bound, how they are to be initialized at the start, 
and how they are to be updated on each iteration. When a 
termination condition is met, the loop exits with a specified 
result value. 

Do expressions are evaluated as follows: The (init) ex¬ 
pressions are evaluated (in some unspecified order), the 
(variable)s are bound to fresh locations, the results of 
the (init) expressions are stored in the bindings of the 
(variable)s, and then the iteration phase begins. 

Each iteration begins by evaluating (test); if the result is 
false (see section 6.1), then the (command) expressions are 
evaluated in order for effect, the (step) expressions are eval¬ 
uated in some unspecified order, the (variable)s are bound 
to fresh locations, the results of the (step)s are stored in the 
bindings of the (variable)s, and the next iteration begins. 

If (test) evaluates to a true value, then the (expression)s 
are evaluated from left to right and the value of the last 
(expression) is returned as the value of the do expression. 
If no (expression)s are present, then the value of the do 
expression is unspecified. 

The region of the binding of a (variable) consists of the 
entire do expression except for the (init)s. It is an error 
for a (variable) to appear more than once in the list of do 
variables. 

A (step) may be omitted, in which case the effect is the 
same as if ((variable) (init) (variable)) had been written 
instead of ((variable) (init)). 

(do ((vec (make-vector 5)) 

(i 0 (+ i 1))) 

((= i 5) vec) 

(vector-set! vec i i)) =4- #(0 1 2 3 4) 

(let ((x >(1357 9))) 

(do ((x x (cdr x)) 

(sum 0 (+ sum (car x)))) 

((null? x) sum))) =>■ 25 

(let (variable) (bindings) (body)) syntax 

Some implementations of Scheme permit a variant on the 
syntax of let called “named let” which provides a more 


general looping construct than do, and may also be used 
to express recursions. 

Named let has the same syntax and semantics as ordi¬ 
nary let except that (variable) is bound within (body) to 
a procedure whose formal arguments are the bound vari¬ 
ables and whose body is (body). Thus the execution of 
(body) may be repeated by invoking the procedure named 
by (variable). 

(let loop ((numbers ’(3-216 -5)) 

(nonneg ’()) 

(neg ’())) 

(cond ((null? numbers) (list nonneg neg)) 

((>= (car numbers) 0) 

(loop (cdr numbers) 

(cons (car numbers) nonneg) 
neg)) 

((< (car numbers) 0) 

(loop (cdr numbers) 
nonneg 

(cons (car numbers) neg))))) 

=*> ((6 1 3) (-5 -2)) 

4.2.5. Delayed evaluation 

(delay (expression)) syntax 

The delay construct is used together with the procedure 
force to implement lazy evaluation or call by need, (delay 
(expression)) returns an object called a promise which at 
some point in the future may be asked (by the force pro¬ 
cedure) to evaluate (expression) and deliver the resulting 
value. 

See the description of force (section 6.9) for a more com¬ 
plete description of delay. 

4.2.6. Quasiquotation 

(quasiquote (template)) essential syntax 

' (template) essential syntax 

“Backquote” or “quasiquote” expressions are useful for 
constructing a list or vector structure when most but not 
all of the desired structure is known in advance. If no 
commas appear within the (template), the result of evalu¬ 
ating ' (template) is equivalent to the result of evaluating 
’(template). If a comma appears within the (template), 
however, the expression following the comma is evaluated 
(“unquoted”) and its result is inserted into the structure 
instead of the comma and the expression. If a comma ap¬ 
pears followed immediately by an at-sign (a), then the fol¬ 
lowing expression must evaluate to a list; the opening and 
closing parentheses of the list are then “stripped away” and 
the elements of the list are inserted in place of the comma 
at-sign expression sequence. 
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'(list ,<+ 1 2) 4) =4> (list 3 4) 

(let ((name ’a)) '(list ,name ’.name)) 

=> (list a (quote a)) 

'(a , (+ 1 2) , @(map abs ’(4 -5 6)) b) 

=#> (a 3 4 5 6 b) 

'((foo ,(- 10 3)) ,S(cdr ’(c)) . ,(car ’(cons))) 
=$■ ((foo 7) . cons) 

'#(10 5 ,(sqrt 4) ,@(map sqrt ’(16 9)) 8) 

=*■ #(10 5 2 4 3 8) 

Quasiquote forms may be nested. Substitutions are made 
only for unquoted components appearing at the same nest¬ 
ing level as the outermost backquote. The nesting level in¬ 
creases by one inside each successive quasiquotation, and 
decreases by one inside each unquotation. 

'(a '(b ,(+ 1 2) ,(foo ,(+13) d) e) f) 

=* (a '(b ,(+ 1 2) , (foo 4 d) e) f) 
(let ((namel ’x) 

(name2 ’y)) 

'(a ' (b ,,namel ,’,name2 d) e)) 

==>• (a ' (b ,x , ’y d) e) 

The notations '(template) and (quasiquote (template)) 
are identical in all respects. , (expression) is identical to 
(unquote (expression)), and , ©(expression) is identical to 
(unquote-splicing (expression)). The external syntax 
generated by write for two-element lists whose car is one 
of these symbols may vary between implementations. 

(quasiquote (list (unquote (+ 1 2)) 4)) 

=£■ (list 3 4) 

’(quasiquote (list (unquote (+ 1 2)) 4)) 

=> '(list ,(+12) 4) 
i.e., (quasiquote (list (unquote (+ 1 2)) 4)) 

Unpredictable behavior can result if any of the symbols 
quasiquote, unquote, or unquote-splicing appear in 
positions within a (template) otherwise than as described 
above. 

5. Program structure 
5.1. Programs 

A Scheme program consists of a sequence of expressions 
and definitions. Expressions are described in .chapter 4; 
definitions are the subject of the rest of the present chapter. 

Programs are typically stored in files or entered inter¬ 
actively to a running Scheme system, although other 
paradigms are possible; questions of user interface lie out¬ 
side the scope of this report. (Indeed, Scheme would still be 
useful as a notation for expressing computational methods 
even in the absence of a mechanical implementation.) 

Definitions occurring at the top level of a program can be 
interpreted declaratively. They cause bindings to be cre¬ 
ated in the top level environment. Expressions occurring 
at the top level of a program are interpreted imperatively; 
they are executed in order when the program is invoked or 
loaded, and typically perform some kind of initialization. 


5.2. Definitions 

Definitions are valid in some, but not all, contexts where 
expressions are allowed. They are valid only at the top 
level of a (program) and, in some implementations, at the 
beginning of a (body). 

A definition should have one of the following forms: 

• (define (variable) (expression)) 

This syntax is essential. 

• (define ((variable) (formals)) (body)) 

This syntax is not essential. (Formals) should be ei¬ 
ther a sequence of zero or more variables, or a sequence 
of one or more variables followed by a space-delimited 
period and another variable (as in a lambda expres¬ 
sion). This form is equivalent to 

(define (variable) 

(lambda ((formals)) (body))). 

• (define ((variable) . (formal)) (body)) 

This syntax is not essential. (Formal) should be a 
single variable. This form is equivalent to 

(define (variable) 

(lambda (formal) (body))). 

• (begin (definitioni) ...) 

This syntax is essential. This form is equivalent to the 
set of definitions that form the body of the begin. 

5.2.1. Top level definitions 

At the top level of a program, a definition 

(define (variable) (expression)) 

has essentially the same effect as the assignment expres¬ 
sion 

(set! (variable) (expression)) 

if (variable) is bound. If (variable) is not bound, however, 
then the definition will bind (variable) to a new location 
before performing the assignment, whereas it would be an 
error to perform a set! on an unbound variable. 

(define add3 

(lambda (x) (+ x 3))) 

(add3 3) =4> 6 

(define first car) 

(first ’(12)) =#> 1 

All Scheme implementations must support top level defini¬ 
tions. 

Some implementations of Scheme use an initial environ¬ 
ment in which all possible variables are bound to locations, 
most of which contain undefined values. Top level defini¬ 
tions in such an implementation are truly equivalent to 
assignments. 
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5.2.2. Internal definitions 

Some implementations of Scheme permit definitions to oc¬ 
cur at the beginning of a {body} (that is, the body of a 
lambda, let, let*, letrec, or define expression). Such 
definitions are known as internal definitions as opposed to 
the top level definitions described above. The variable de¬ 
fined by an internal definition is local to the (body). That 
is, (variable) is bound rather than assigned, and the region 
of the binding is the entire (body). For example, 

(let ((x 5)) 

(define foo (lambda (y) (bar x y))> 

(define bar (lambda (a b) (+ (* a b) a))) 

(foo (+ x 3))) => 45 

A (body) containing internal definitions can always be con¬ 
verted into a completely equivalent letrec expression. For 
example, the let expression in the above example is equiv¬ 
alent to 

(let ((x 5)) 

(letrec ((foo (lambda (y) (bar x y))> 

(bar (lambda (a b) (+ (* a b) a)))) 

(foo (+ x 3)))) 

Just as for the equivalent letrec expression, it must be 
possible to evaluate each (expression) of every internal def¬ 
inition in a (body) without assigning or referring to the 
value of any (variable) being defined. 


Note: In some implementations the empty list counts as false, 
contrary to the above. Nonetheless a few examples in this report 
assume that the empty list counts as true, as in [50], 

Note: Programmers accustomed to other dialects of Lisp 

should be aware that Scheme distinguishes both #f and the 
empty list from the symbol nil. 

Boolean constants evaluate to themselves, so they don’t 
need to be quoted in programs. 

#t =>■ #t 

#f =£• #f 

’#f =*> #f 


(not obj) essential procedure 

Not returns #t if obj is false, and returns #f otherwise. 


(not #t) 


#f 

(not 3) 


#f 

(not (list 3)) 

==» 

#f 

(not #f) 

=*> 

#t 

(not ’()) 


#f 

(not (list)) 


#f 

(not ’nil) 




(boolean? obj ) essential procedure 

Boolean? returns #t if obj is either #t or #f and returns 
#f otherwise. 


6. Standard procedures 

This chapter describes Scheme’s built-in procedures. The 
initial (or “top level”) Scheme environment starts out with 
a number of variables bound to locations containing useful 
values, most of which are primitive procedures that manip¬ 
ulate data. For example, the variable abs is bound to (a 
location initially containing) a procedure of one argument 
that computes the absolute value of a number, and the 
variable + is bound to a procedure that computes sums. 

6.1. Booleans 

The standard boolean objects for true and false are written 
as #t and #f. What really matters, though, are the objects 
that the Scheme conditional expressions (if, cond, and, 
or, do) treat as true or false. The phrase “a true value” 
(or sometimes just “true”) means any object treated as 
true by the conditional expressions, and the phrase “a false 
value” (or “false”) means any object treated as false by the 
conditional expressions. 

Of all the standard Scheme values, only #f counts as false 
in conditional expressions. Except for #f, all standard 
Scheme values, including #t, pairs, the empty list, sym¬ 
bols, numbers, strings, vectors, and procedures, count as 
true. 


(boolean? #f) 


#t 

(boolean? 0) 

=> 

#f 

(boolean? ’()) 

=$. 

#f 


6.2. Equivalence predicates 

A predicate is a procedure that always returns a boolean 
value (#t or #f). An equivalence predicate is the compu¬ 
tational analogue of a mathematical equivalence relation 
(it is symmetric, reflexive, and transitive). Of the equiva¬ 
lence predicates described in this section, eq? is the finest 
or most discriminating, and equal? is the coarsest. Eqv? 
is slightly less discriminating than eq?. 

(eqv? obji objz) essential procedure 

The eqv? procedure defines a useful equivalence relation 
on objects. Briefly, it returns #t if obji and obj 2 should 
normally be regarded as the same object. This relation is 
left slightly open to interpretation, but the following par¬ 
tial specification of eqv? holds for all implementations of 
Scheme. 

The eqv? procedure returns #t if: 

• obji and obj 2 are both #t or both #f. 

• obji and objn are both symbols and 
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(string=? (symbol->string objl) 
(symbol->string obj2)) 

==> #t 

Note: This assumes that neither obji nor 0 &J 2 is an “un- 
interned symbol” as alluded to in section 6.4. This re¬ 
port does not presume to specify the behavior of eqv? on 
implementation-dependent extensions. 

• obji and obji are both numbers, are numerically equal 
(see =, section 6.5), and are either both exact or both 
inexact. 

• obji and obj 2 are both characters and are the same 
character according to the char=? procedure (sec¬ 
tion 6.6). 

• both obji and obji are the empty list. 

• obji and obj 2 are pairs, vectors, or strings that denote 
the same locations in the store (section 3.5). 

• obji and obji are procedures whose location tags are 
equal (section 4.1.4). 

The eqv? procedure returns #f if: 

• obji and obji are of different types (section 3.4). 

• one of obji and obji is #t but the other is #f. 

• obji and obji are symbols but 

(string=? (symbol->string obji) 

(symbol->string obji)) 

=*• #f 

• one of obji and obji is an exact number but the other 
is an inexact number. 

• obji and obji are numbers for which the = procedure 
returns #f. 

• obji and obji are characters for which the char=? pro¬ 
cedure returns #f. 

• one of obji and obji is the empty list but the other is 

not. ... 

• obji and obji are pairs, vectors, or strings that denote 
distinct locations. 


(lambda () 2)) => #f 

(eqv? #f ’nil) => #f 

(let ((p (lambda (x) x))) 

(eqv? p p)) =$• #t 

The following examples illustrate cases in which the above 
rules do not fully specify the behavior of eqv?. All that 
can be said about such cases is that the value returned by 


eqv? must be a boolean. 



(eqv? 

Ill) Mil) 


unspecified 

(eqv? 

’#() ’#()) 

=> 

unspecified 

(eqv? 

(lambda (x) x) 
(lambda (x) x)) 

=4> 

unspecified 

(eqv? 

(lambda (x) x) 
(lambda (y) y)) 


unspecified 


The next set of examples shows the use of eqv? with pro¬ 
cedures that have local state. Gen-counter must return a 
distinct procedure every time, since each procedure has its 
own internal counter. Gen-loser, however, returns equiv¬ 
alent procedures each time, since the local state does not 
affect the value or side effects of the procedures. 

(define gen-counter 
(lambda () 

(let ((n 0)) 

(lambda 0 (set! n (+ n 1)) n)))) 

(let ((g (gen-counter))) 

(eqv? g g)) => #t 

(eqv? (gen-counter) (gen-counter)) 

=4- #f 

(define gen-loser 
(lambda () 

(let ((n 0)) 

(lambda () (set! n (+ n 1)) 27)))) 

(let ((g (gen-loser))) 

(eqv? g g)) =>• #t 

(eqv? (gen-loser) (gen-loser)) 

=£■ unspecified 

(letrec ((f (lambda () (if (eqv? f g) ’both ’f))) 

(g (lambda () (if (eqv? f g) ’both ’g))) 

(eqv? f g)) 

=> unspecified 


(letrec ((f (lambda () (if (eqv? f g) ’f ’both))) 
(g (lambda 0 (if (eqv? f g) ’g ’both))) 
(eqv? f g)) 


==? #f 


• obji and obj 2 are procedures that would behave dif¬ 
ferently (return a different value or have different side 
effects) for some arguments. 

(eqv? ’a ’a) => #t 

(eqv? ’a ’b) =>■ #f 

(eqv? 22) ==? #t 

(eqv? ’() ’()) =? #t 

(eqv? 100000000 100000000) => #t 

(eqv? (cons 1 2) (cons 1 2))==> #f 

(eqv? (lambda () 1) 


Since it is an error to modify constant objects (those re¬ 
turned by literal expressions), implementations are per¬ 
mitted, though not required, to share structure between 
constants where appropriate. Thus the value of eqv? on 
constants is sometimes implementation-dependent. 

(eqv? ’(a) ’(a)) => unspecified 

(eqv? "a" "a") => unspecified 

(eqv? ’(b) (cdr ’(a b))) =$>• unspecified 

(let ((x ’(a))) 

(eqv? x x)) =£- #t 
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Rationale: The above definition of eqv? allows implementa¬ 
tions latitude in their treatment of procedures and literals: im¬ 
plementations are free either to detect or to fail to detect that 
two procedures or two literals are equivalent to each other, and 
can decide whether or not to merge representations of equivalent 
objects by using the same pointer or bit pattern to represent 
both. 


(eq? obji 0 &J 2 ) essential procedure 

Eq? is similar to eqv? except that in some cases it is capable 
of discerning distinctions finer than those detectable by 
eqv?. 

Eq? and eqv? are guaranteed to have the same behavior 
on symbols, booleans, the empty list, pairs, and non-empty 
strings and vectors. Eq?’s behavior on numbers and charac¬ 
ters is implementation-dependent, but it will always return 
either true or false, and will return true only when eqv? 
would also return true. Eq? may also behave differently 


1 eqv? on empty vectors and empty 

strings. 

(eq? ’a ’a) 

=k 

#t 

(eq? ’(a) ’(a)) 

==^ 

unspecified 

(eq? (list ’a) (list ’a)) 

=*• 

#f 

(eq? "a" "a") 

=*• 

unspecified 

(eq? "" "") 

=$- 

unspecified 

(eq? >() ’()) 

==> 

#t 

(eq? 2 2) 


unspecified 

(eq? #\A #\A) 

==> 

unspecified 

(eq? car car) 

(let ((n (+ 2 3))) 


#t 

(eq? n n)) 

(let ((x ’(a))) 


unspecified 

(eq? x x)) 

(let ((x ’#())) 


#t 

(eq? x x)) 

(let ((p (lambda (x) x))) 


#t 

(eq? p p)) 

=> 

# t 


Rationale: It will usually be possible to implement eq? much 
more efficiently than eqv?, for example, as a simple pointer com¬ 
parison instead of as some more complicated operation. One 
reason is that it may not be possible to compute eqv? of two 
numbers in constant time, whereas eq? implemented as pointer 
comparison will always finish in constant time. Eq? may be used 
like eqv? in applications using procedures to implement objects 
with state since it obeys the same constraints as eqv?. 


(equal? obji obj'fi) essential procedure 

Equal? recursively compares the contents of pairs, vectors, 
and strings, applying eqv? on other objects such as num¬ 
bers and symbols. A rule of thumb is that objects are 
generally equal? if they print the same. Equal? may fail 
to terminate if its arguments are circular data structures. 

(equal? ’a ’a) =>• #t 

(equal? ’(a) ’(a)) ==> #t 


(equal? ’(a (b) c) 

’(a (b) c)) 

(equal? "abc" "abc") 

(equal? 2 2) 

(equal? (make-vector 5 ’a) 
(make-vector 5 ’a)) 
(equal? (lambda (x) x) 
(lambda (y) y)) 


#t 

#t 

#t 

#t 

unspecified 


6.3. Pairs and lists 


A pair (sometimes called a dotted pair) is a record structure 
with two fields called the car and cdr fields (for historical 
reasons). Pairs are created by the procedure cons. The 
car and cdr fields are accessed by the procedures car and 
cdr. The car and cdr fields are assigned by the procedures 
set-car! and set-cdr!. 

Pairs are used primarily to represent lists. A list can be 
defined recursively as either the empty list or a pair whose 
cdr is a list. More precisely, the set of lists is defined as 
the smallest set X such that 


• The empty list is in X. 

• If list is in A, then any pair whose cdr field contains 
list is also in X. 


The objects in the car fields of successive pairs of a list are 
the elements of the list. For example, a two-element list 
is a pair whose car is the first element and whose cdr is a 
pair whose car is the second element and whose cdr is the 
empty list. The length of a list is the number of elements, 
which is the same as the number of pairs. 

The empty list is a special object of its own type (it is not 
a pair); it has no elements and its length is zero. 

Note: The above definitions imply that all lists have finite 

length and are terminated by the empty list. 

The most general notation (external representation) for 
Scheme pairs is the “dotted” notation (ci . c 2 ) where Ci 
is the value of the car field and c 2 is the value of the cdr 
field. For example (4 . 5) is a pair whose car is 4 and 
whose cdr is 5. Note that (4 . 5) is the external repre¬ 
sentation of a pair, not an expression that evaluates to a 
pair. 

A more streamlined notation can be used for lists: the 
elements of the list are simply enclosed in parentheses and 
separated by spaces. The empty list is written () . For 
example, 


(a b c d e) 


and 


(a . (b . (c . (d . (e . ()))))) 
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are equivalent notations for a list of symbols. 

A chain of pairs not ending in the empty list is called an 
improper list. Note that an improper list is not a list. 
The list and dotted notations can be combined to represent 
improper lists: 

(a b c . d) 

is equivalent to 

(a . (b . (c . d))> 

Whether a given pair is a list depends upon what is stored 
in the cdr field. When the set-cdr! procedure is used, an 
object can be a list one moment and not the next: 


(define x (list 

’a ’b ’c)) 


(define y x) 



y 

=> 

(a b c) 

(list? y) 

=> 

#t 

(set-cdr! x 4) 

=> 

unspecified 

X 

=> 

(a . 4) 

(eqv? x y) 

=*• 

#t 

y 

=*• 

(a . 4) 

(list? y) 


#f 

(set-cdr! x x) 

==> 

unspecified 

(list? x) 


#f 


Within literal expressions and representations of ob¬ 
jects read by the read procedure, the forms ’(datum), 
'(datum), ,(datum), and ,®(datum) denote two-ele¬ 
ment lists whose first elements are the symbols quote, 
quasiquote, unquote, and unquote-splicing, respec¬ 
tively. The second element in each case is (datum). This 
convention is supported so that arbitrary Scheme pro¬ 
grams may be represented as lists. That is, according 
to Scheme’s grammar, every (expression) is also a (datum) 
(see section 7.1.2). Among other things, this permits the 
use of the read procedure to parse Scheme programs. See 
section 3.3. 

(pair? obj ) essential procedure 

Pair? returns #t if obj is a pair, and otherwise returns #f. 


(pair? 

’ (a . 

b)) 


#t 

(pair? 

’ (a b 

c)) 


#t 

(pair? 

’()) 



#f 

(pair? 

’#(a 

b)) 


#f 


(car pair ) essential procedure 

Returns the contents of the car field of pair. Note that it 
is an error to take the car of the empty list. 


(car 

’ (a b 

c)) 

=> 

a 

(car 

’((a) 

bed)) 

=> 

(a) 

(car 

’(1 . 

2)) 

=*■ 

1 

(car 

’()) 


=> 

error 


(cdr pair ) essential procedure 

Returns the contents of the cdr field of pair. Note that it 
is an error to take the cdr of the empty list. 

(cdr ’((a) bed)) =>• (b c d) 

(cdr ’(1.2)) => 2 

(cdr ’()) ==> error 


(set-car! pair obj ) essential procedure 

Stores obj in the car field of pair. The value returned by 
set-car! is unspecified. 

(define (f) (list ’not-a-constant-list)) 

(define (g) ’(constant-list)) 

(set-car! (f) 3) =► unspecified 

(set-car! (g) 3) => error 

(set-cdr! pair obj ) essential procedure 

Stores obj in the cdr field of pair. The value returned by 
set-cdr! is unspecified. 


(caar pair) 
(cadr pair) 


essential procedure 
essential procedure 


(edddar pair) essential procedure 

(eddddr pair) essential procedure 

These procedures are compositions of car and cdr, where 
for example caddr could be defined by 

(define caddr (lambda (x) (car (cdr (cdr x))))). 

Arbitrary compositions, up to four deep, are provided. 
There are twenty-eight of these procedures in all. 


(cons obji obj 2 ) essential procedure 

Returns a newly allocated pair whose car is obji and whose 
cdr is obj 2 - The pair is guaranteed to be different (in the 
sense of eqv?) from every existing object. 


(cons 

(cons 

(cons 

(cons 

(cons 


’a ’()) 

’ (a) ’ (b c d)) 
"a" ’(b c)) 

’a 3) 

’(a b) ’c) 


(a) 

((a) be d) 
("a" b c) 

(a . 3) 

((a b) . c) 


(null? obj) essential procedure 

Returns #t if obj is the empty list, otherwise returns #f. 

(list? obj) essential procedure 

Returns #t if obj is a list, otherwise returns #f. By defini¬ 
tion, all lists have finite length and are terminated by the 
empty list. 
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(list? ’(a b c)) =4 #t 

(list? ’()) =4 #t 

(list? ’(a . b)) =4 #f 

(let ((x (list ’a))) 
(set-cdr! x x) 

(list? x)) =4 #f 


(list obj 


essential procedure 


(list-ref &) essential procedure 

Returns the Jbth element of list. (This is the same as the 
car of (list-tail list k ).) 

(list-ref ’(abed) 2) =4 c 

(list-ref ’(abed) 

(inexact->exact (round 1.8))) 


Returns a newly allocated list of its arguments. 


(list ’a (+ 3 4) ’c) 
(list) 


(a 7 c) 

() 


(length list ) 

Returns the length of list. 

(length ’(a b c)) 

(length ’(a (b) (c d e))) 
(length ’()) 


essential procedure 


=4- 3 

=4- 3 

=4 0 


(append list ...) essential procedure 

Returns a list consisting of the elements of the first list 
followed by the elements of the other lists. 


(append ’(x) ’(y)) 
(append ’(a) ’(b c d)) 
(append ’(a (b)) ’((c))) 


=4 (x y) 

=4 (abed) 
=4- (a (b) (c)) 


(memq obj list ) essential procedure 

(memv obj list ) essential procedure 

(member obj list ) essential procedure 

These procedures return the first sublist of list whose car 

is obj, where the sublists of list are the non-empty lists 
returned by (list-tail list k ) for k less than the length 
of list. If obj does not occur in list, then #f (not the empty 
list) is returned. Memq uses eq? to compare obj with the 
elements of list, while memv uses eqv? and member uses 
equal?. 


(memq ’a ’(a b c)) 

=4 

(a b c) 

(memq ’b ’(a b c)) 

=4 

(b c) 

(memq ’a ’(b c d)) 

=4 

#f 

(memq (list ’a) ’(b 

(a) c)) =4 

#f 

(member (list ’a) 



’(b (a) c)) 

=4 

((a) c) 

(memq 101 ’(100 101 

102)) =4 

unspecified 

(memv 101 ’(100 101 

102)) =4 

(101 102) 


The resulting list is always newly allocated, except that 
it shares structure with the last list argument. The last 
argument may actually be any object; an improper list 
results if the last argument is not a proper list. 

(append ’(a b) ’ (c . d)) =4 (a b c . d) 

(append ’() ’a) =4- a 

(reverse list ) essential procedure 


(assq obj alist ) essential procedure 

(assv obj alist ) essential procedure 

(assoc obj alist ) essential procedure 

Alist (for “association list”) must be a list of pairs. These 
procedures find the first pair in alist whose car field is obj, 
and returns that pair. If no pair in alist has obj as its car, 
then #f (not the empty list) is returned. Assq uses eq? to 
compare obj with the car fields of the pairs in alist, while 
assv uses eqv? and assoc uses equal?. 


Returns a newly allocated list consisting of the elements of 
list in reverse order. 

(reverse ’ (a b c)) =4- (c b a) 

(reverse ’(a (b c) d (e (f)))) 

=4 ((e (f)) d (b c) a) 


(list-tail list k) procedure 

Returns the sublist of list obtained by omitting the first k 
elements. List-tail could be defined by 


(define e ’((a 1) (b 2) (c 3))) 

(assq ’a e) =4 (a 1) 

(assq ’b e) =4 (b 2) 

(assq ’d e) =4 #f 

(assq (list ’a) ’(((a)) ((b)) ((c)))) 

=4 #f 

(assoc (list ’a) ’(((a)) ((b)) ((c)))) 

=4 ((a)) 

(assq 5 ’((2 3) (5 7) (11 13))) 

=4 unspecified 

(assv 5 ’((2 3) (5 7) (11 13))) 

=4- (5 7) 


(define list-tail 
(lambda (x k) 

(if (zero? k) 
x 

(list-tail (edr x) (- k 1))))) 


Rationale: Although they are ordinarily used as predicates, 
memq, memv, member, assq, assv, and assoc do not have question 
marks in their names because they return useful values rather 
than just #t or #f. 
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6.4. Symbols 

Symbols are objects whose usefulness rests on the fact that 
two symbols are identical (in the sense of eqv?) if and only 
if their names are spelled the same way. This is exactly the 
property needed to represent identifiers in programs, and 
so most implementations of Scheme use them internally for 
that purpose. Symbols are useful for many other applica¬ 
tions; for instance, they may be used the way enumerated 
values are used in Pascal. 

The rules for writing a symbol are exactly the same as the 
rules for writing an identifier; see sections 2.1 and 7.1.1. 

It is guaranteed that any symbol that has been returned as 
part of a literal expression, or read using the read proce¬ 
dure, and subsequently written out using the write proce¬ 
dure, will read back in as the identical symbol (in the sense 
of eqv?). The string->symbol procedure, however, can 
create symbols for which this write/read invariance may 
not hold because their names contain special characters or 
letters in the non-standard case. 

Note: Some implementations of Scheme have a feature known 
as “slashification” in order to guarantee write/read invariance 
for all symbols, but historically the most important use of this 
feature has been to compensate for the lack of a string data 
type. 

Some implementations also have “uninterned symbols”, which 
defeat write/read invariance even in implementations with 
slashification, and also generate exceptions to the rule that two 
symbols are the same if and only if their names are spelled the 
same. 


(symbol? obj ) essential procedure 

Returns #t if obj is a symbol, otherwise returns #f . 


(symbol? ’foo) 


#t 

(symbol? (car ’(ab))) 

=> 

#t 

(symbol? "bar") 

=4- 

#f 

(symbol? ’nil) 

=> 

#t 

(symbol? ’()) 

=4> 

#f 

(symbol? #f) 


#f 

(symbol->string symbol ) 


essential procedure 


Returns the name of symbol as a string. If the symbol was 
part of an object returned as the value of a literal expres¬ 
sion (section 4.1.2) or by a call to the read procedure, and 
its name contains alphabetic characters, then the string 
returned will contain characters in the implementation’s 
preferred standard case—some implementations will prefer 
upper case, others lower case. If the symbol was returned 
by string->symbol, the case of characters in the string 
returned will be the same as the case in the string that 
was passed to string->symbol. It is an error to apply 
mutation procedures like string-set! to strings returned 
by this procedure. 


The following examples assume that the implementation’s 
standard case is lower case: 

(symbol->string ’flying-fish) 

=> "flying-fish" 

(symbol->string ’Martin) =>■ “martin" 
(symbol->string 

(string->symbol "Malvina")) 

==> "Malvina" 


(string->symbol string) essential procedure 

Returns the symbol whose name is string. This procedure 
can create symbols with names containing special charac¬ 
ters or letters in the non-standard case, but it is usually 
a bad idea to create such symbols because in some imple¬ 
mentations of Scheme they cannot be read as themselves. 
See symbol->string. 

The following examples assume that the implementation’s 
standard case is lower case: 

(eq? ’mISSISSIppi ’mississippi) 

==» #t 

(string->symbol "mISSISSIppi") 

==> the symbol with name "mISSISSIppi" 
(eq? ’bitBlt (string->symbol "bitBlt")) 

=>• #f 
(eq? ’JollyWog 

(string->symbol 

(symbol->string ’JollyWog))) 

=> #t 

(string=? "K. Harper, M.D." 

(symbol->string 

(string->symbol "K. Harper, M.D."))) 
=4* #t 


6.5. Numbers 

Numerical computation has traditionally been neglected 
by the Lisp community. Until Common Lisp there was 
no carefully thought out strategy for organizing numerical 
computation, and with the exception of the MacLisp sys¬ 
tem [62] little effort was made to execute numerical code 
efficiently. This report recognizes the excellent work of the 
Common Lisp committee and accepts many of their rec¬ 
ommendations. In some ways this report simplifies and 
generalizes their proposals in a manner consistent with the 
purposes of Scheme. 

It is important to distinguish between the mathemati¬ 
cal numbers, the Scheme numbers that attempt to model 
them, the machine representations used to implement the 
Scheme numbers, and notations used to write numbers. 
This report uses the types number, complex, real, rational, 
and integer to refer to both mathematical numbers and 
Scheme numbers. Machine representations such as fixed 
point and floating point are referred to by names such as 
fixnum and flonum. 
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6.5.1. Numerical types 

Mathematically, numbers may be arranged into a tower of 
subtypes in which each level is a subset of the level above 
it: 

number 

complex 

real 

rational 

integer 

For example, 3 is an integer. Therefore 3 is also a rational, 
a real, and a complex. The same is true of the Scheme 
numbers that model 3. For Scheme numbers, these types 
are defined by the predicates number?, complex?, real?, 
rational?, and integer?. 

There is no simple relationship between a number’s type 
and its representation inside a computer. Although most 
implementations of Scheme will offer at least two different 
representations of 3, these different representations denote 
the same integer. 

Scheme’s numerical operations treat numbers as abstract 
data, as independent of their representation as possible. 
Although an implementation of Scheme may use fixnum, 
flonum, and perhaps other representations for numbers, 
this should not be apparent to a casual programmer writing 
simple programs. 

It is necessary, however, to distinguish between numbers 
that are represented exactly and those that may not be. 
For example, indexes into data structures must be known 
exactly, as must some polynomial coefficients in a symbolic 
algebra system. On the other hand, the results of measure¬ 
ments are inherently inexact, and irrational numbers may 
be approximated by rational and therefore inexact approx¬ 
imations. In order to catch uses of inexact numbers where 
exact numbers are required, Scheme explicitly distinguishes 
exact from inexact numbers. This distinction is orthogonal 
to the dimension of type. 

6.5.2. Exactness 

Scheme numbers are either exact or inexact. A number is 
exact if it was written as an exact constant or was derived 
from exact numbers using only exact operations. A number 
is inexact if it was written as an inexact constant, if it 
was derived using inexact ingredients, or if it was derived 
using inexact operations. Thus inexactness is a contagious 
property of a number. 

If two implementations produce exact results for a com¬ 
putation that did not involve inexact intermediate results, 
the two ultimate results will be mathematically equivalent. 
This is generally not true of computations involving inex¬ 
act numbers since approximate methods such as floating 
point arithmetic may be used, but it is the duty of each 


implementation to make the result as close as practical to 
the mathematically ideal result. 

Rational operations such as + should always produce ex¬ 
act results when given exact arguments. If the operation 
is unable to produce an exact result, then it may either 
report the violation of an implementation restriction or it 
may silently coerce its result to an inexact value. See sec¬ 
tion 6.5.3. 

With the exception of inexact->exact, the operations de¬ 
scribed in this section must generally return inexact results 
when given any inexact arguments. An operation may, 
however, return an exact result if it can prove that the 
value of the result is unaffected by the inexactness of its 
arguments. For example, multiplication of any number by 
an exact zero may produce an exact zero result, even if the 
other argument is inexact. 

6.5.3. Implementation restrictions 

Implementations of Scheme are not required to implement 
the whole tower of subtypes given in section 6.5.1, but 
they must implement a coherent subset consistent with 
both the purposes of the implementation and the spirit 
of the Scheme language. For example, an implementation 
in which all numbers are real may still be quite useful. 

Implementations may also support only a limited range of 
numbers of any type, subject to the requirements of this 
section. The supported range for exact numbers of any 
type may be different from the supported range for inex¬ 
act numbers of that type. For example, an implementation 
that uses flonums to represent all its inexact real numbers 
may support a practically unbounded range of exact inte¬ 
gers and rationals while limiting the range of inexact reals 
(and therefore the range of inexact integers and rationals) 
to the dynamic range of the flonum format. Furthermore 
the gaps between the representable inexact integers and ra¬ 
tionals are likely to be very large in such an implementation 
as the limits of this range are approached. 

An implementation of Scheme must support exact integers 
throughout the range of numbers that may be used for 
indexes of lists, vectors, and strings or that may result 
from computing the length of a list, vector, or string. The 
length, vector-length, and string-length procedures 
must return an exact integer, and it is an error to use 
anything but an exact integer as an index. Furthermore 
any integer constant within the index range, if expressed 
by an exact integer syntax, will indeed be read as an exact 
integer, regardless of any implementation restrictions that 
may apply outside this range. Finally, the procedures listed 
below will always return an exact integer result provided all 
their arguments are exact integers and the mathematically 
expected result is representable as an exact integer within 
the implementation: 
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+ 

quotient 

max 

numerator 

lent 

truncate 

expt 


remainder 

min 

denominator 

floor 

round 


* 

modulo 

abs 

ged 

ceiling 

rationalize 


Implementations are encouraged, but not required, to sup¬ 
port exact integers and exact rationals of practically unlim¬ 
ited size and precision, and to implement the above proce¬ 
dures and the / procedure in such a way that they always 
return exact results when given exact arguments. If one of 
these procedures is unable to deliver an exact result when 
given exact arguments, then it may either report a vio¬ 
lation of an implementation restriction or it may silently 
coerce its result to an inexact number. Such a coercion 
may cause an error later. 

An implementation may use floating point and other ap¬ 
proximate representation strategies for inexact numbers. 
This report recommends, but does not require, that the 
IEEE 32-bit and 64-bit floating point standards be followed 
by implementations that use flonum representations, and 
that implementations using other representations should 
match or exceed the precision achievable using these float¬ 
ing point standards [49]. 

In particular, implementations that use flonum represen¬ 
tations must follow these rules: A flonum result must be 
represented with at least as much precision as is used to 
express any of the inexact arguments to that operation. It 
is desirable (but not required) for potentially inexact oper¬ 
ations such as sqrt, when applied to exact arguments, to 
produce exact answers whenever possible (for example the 
square root of an exact 4 ought to be an exact 2). If, how¬ 
ever, an exact number is operated upon so as to produce an 
inexact result (as by sqrt), and if the result is represented 
as a flonum, then the most precise flonum format available 
must be used; but if the result is represented in some other 
way then the representation must have at least as much 
precision as the most precise flonum format available. 

Although Scheme allows a variety of written notations for 
numbers, any particular implementation may support only 
some of them. For example, an implementation in which 
all numbers are real need not support the rectangular and 
polar notations for complex numbers. If an implementa¬ 
tion encounters an exact numerical constant that it cannot 
represent as an exact number, then it may either report a 
violation of an implementation restriction or it may silently 
represent the constant by an inexact number. 


6.5.4. Syntax of numerical constants 

The syntax of the written representations for numbers is 
described formally in section 7.1.1. 

A number may be written in binary, octal, decimal, or hex¬ 
adecimal by the use of a radix prefix. The radix prefixes 


are #b (binary), #o (octal), #d (decimal), and #x (hexadec¬ 
imal). With no radix prefix, a number is assumed to be 
expressed in decimal. 

A numerical constant may be specified to be either exact or 
inexact by a prefix. The prefixes are #e for exact, and #i 
for inexact. An exactness prefix may appear before or after 
any radix prefix that is used. If the written representation 
of a number has no exactness prefix, the constant may be 
either inexact or exact. It is inexact if it contains a decimal 
point, an exponent, or a character in the place of a 
digit, otherwise it is exact. 

In systems with inexact numbers of varying precisions it 
may be useful to specify the precision of a constant. For 
this purpose, numerical constants may be written with an 
exponent marker that indicates the desired precision of the 
inexact representation. The letters s, f, d, and 1 specify 
the use of short, single, double, and long precision, respec¬ 
tively. (When fewer than four internal inexact represen¬ 
tations exist, the four size specifications are mapped onto 
those available. For example, an implementation with two 
internal representations may map short and single together 
and long and double together.) In addition, the exponent 
marker e specifies the default precision for the implemen¬ 
tation. The default precision has at least as much precision 
as double, but implementations may wish to allow this de¬ 
fault to be set by the user. 

3.14159265358979F0 

Round to single — 3.141593 

0.6L0 

Extend to long — .600000000000000 
6.5.5. Numerical operations 

The reader is referred to section 1.3.3 for a summary of 
the naming conventions used to specify restrictions on the 
types of arguments to numerical routines. The examples 
used in this section assume that any numerical constant 
written using an exact notation is indeed represented as 
an exact number. Some examples also assume that certain 
numerical constants written using an inexact notation can 
be represented without loss of accuracy; the inexact con¬ 
stants were chosen so that this is likely to be true in imple¬ 
mentations that use flonums to represent inexact numbers. 


(number? obj) 
(complex? obj ) 
(real? obj) 
(rational? obj) 
(integer? obj) 


essential procedure 
essential procedure 
essential procedure 
essential procedure 
essential procedure 


These numerical type predicates can be applied to any kind 
of argument, including non-numbers. They return #t if the 
object is of the named type, and otherwise they return #f. 
In general, if a type predicate is true of a number then 
all higher type predicates are also true of that number. 
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Consequently, if a type predicate is false of a number, then 
all lower type predicates are also false of that number. 

If z is an inexact complex number, then (real? z) is true 
if and only if (zero? (imag-part z )) is true. If x is an 
inexact real number, then (integer? x) is true if and only 
if (= x (round x)). 


(complex? 3+4i) 

==► 

#t 

(complex? 3) 

=>• 

#t 

(real? 3) 

==> 

#t 

(real? -2.5+0.0i) 

=> 

#t 

(real? #elelO) 

==> 

#t 

(rational? 6/10) 

=4- 

#t 

(rational? 6/3) 


#t 

(integer? 3+0i) 

==> 

#t 

(integer? 3.0) 


#t 

(integer? 8/4) 

=S> 

#t 


Note: The behavior of these type predicates on inexact num¬ 
bers is unreliable, since any inaccuracy may affect the result. 

Note: In many implementations the rational? procedure will 
be the same as real?, and the complex? procedure will be the 
same as number?, but unusual implementations may be able 
to represent some irrational numbers exactly or may extend the 
number system to support some kind of non-complex numbers. 


(exact? z) essential procedure 

(inexact? z ) essential procedure 

These numerical predicates provide tests for the exactness 
of a quantity. For any Scheme number, precisely one of 
these predicates is true. 


(= zi z 2 z 3 ...) 
(< X\ x 2 x 3 ...) 
(> Xi X 2 x 3 . . . ) 
(<= Xi x 2 X 3 . . . ) 
(>= Xi x 2 x 3 . . . ) 


essential procedure 
essential procedure 
essential procedure 
essential procedure 
essential procedure 


These procedures return #t if their arguments are (respec¬ 
tively): equal, monotonically increasing, monotonically de¬ 
creasing, monotonically nondecreasing, or monotonically 
nonincreasing. 

These predicates are required to be transitive. 


Note: The traditional implementations of these predicates in 
Lisp-like languages are not transitive. 


Note: While it is not an error to compare inexact numbers 
using these predicates, the results may be unreliable because a 
small inaccuracy may affect the result; this is especially true of 
= and zero?. When in doubt, consult a numerical analyst. 


(zero? z) essential procedure 

(positive? x) essential procedure 

(negative? x) essential procedure 


(odd? n) essential procedure 

(even? n) essential procedure 

These numerical predicates test a number for a particular 
property, returning #t or #f. See note above. 

(max x\ x 2 ...) essential procedure 

(min x\ x 2 ■ •.) essential procedure 

These procedures return the maximum or minimum of their 
arguments. 

(max 3 4) =>• 4 ; exact 

(max 3.9 4) => 4.0 ; inexact 

Note: If any argument is inexact, then the result will also be 
inexact (unless the procedure can prove that the inaccuracy is 
not large enough to affect the result, which is possible only in 
unusual implementations). If min or max is used to compare 
numbers of mixed exactness, and the numerical value of the 
result cannot be represented as an inexact number without loss 
of accuracy, then the procedure may report a violation of an 
implementation restriction. 


(+ zi ...) essential procedure 

(* zi ...) essential procedure 

These procedures return the sum or product of their argu¬ 
ments. 


(+ 3 4) 

=$- 7 

(+ 3) 

==> 3 

(+) 

=*- 0 

(* 4) 

=>■ 4 

(*) 

1 

(- Zi z 2 ) 

essential procedure 

(- 

essential procedure 

(- Zi z 2 . . . ) 

procedure 

(/ z 1 z 2 ) 

essential procedure 

(/ z) 

essential procedure 

(/ Zi z 2 .. ■ ) 

procedure 

With two or more arguments, these procedures return the 
difference or quotient of their arguments, associating to the 
left. With one argument, however, they return the additive 

or multiplicative 

inverse of their argument. 

(- 3 4) 

=? -1 

(-345) 

=> -6 

(- 3) 

==> -3 

(/ 3 4 5) 

=4- 3/20 

(/ 3) 

==> 1/3 

(abs x ) 

essential procedure 

Abs returns the magnitude of its argument. 

(abs -7) 

=*► 7 
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(quotient ni n 2 ) essential procedure 

(remainder m n 2 ) essential procedure 

(modulo n\ n 2 ) essential procedure 

These procedures implement number-theoretic (integer) di¬ 
vision: For positive integers n x and ri 2 , if n 3 and n 4 are 
integers such that n x = n 2 n 3 + n 4 and 0 < n 4 < n 2 , then 


(quotient n 1 112 ) 

=>- 

nz 

(remainder n\ n 2 ) 

==> 

tt4 

(modulo ni « 2 ) 

==> 

n4 


For integers n x and n 2 with n 2 not equal to 0, 

(= n\ (+ (* «2 (quotient n\ n 2 )) 

(remainder n\ 712))) 

=>• # t 

provided all numbers involved in that computation are ex¬ 
act. 

The value returned by quotient always has the sign of the 
product of its arguments. Remainder and modulo differ on 
negative arguments—the remainder is either zero or has 
the sign of the dividend, while the modulo always has the 
sign of the divisor: 


(modulo 13 4) 

(remainder 13 4) 

=> 1 


(modulo -13 4) 

(remainder -13 4) 

- K 


(modulo 13 -4) 

(remainder 13 -4) 

2 ; 3 


(modulo -13 -4) 
(remainder -13 -4) 

11 

1 1 

»-*■ M- 


(remainder -13 -4.0) 

—1.0 ; 

inexact 

(gcd ni ... ) 

(1cm n x ... ) 

essential procedure 
essential procedure 

These procedures return the greatest common divisor or 
least common multiple of their arguments. The result is 
always non-negative. 

(gcd 32 -36) 

(gcd) 

(1cm 32 -36) 

(1cm 32.0 -36) 

(1cm) 

O 

CO 00 

CO 00 

^ 0 M (N H 

11(1 If It 

; inexact 

(numerator q ) 

(denominator q) 


procedure 

procedure 


These procedures return the numerator or denominator of 
their argument; the result is computed as if the argument 
was represented as a fraction in lowest terms. The denom¬ 
inator is always positive. The denominator of 0 is defined 
to be 1. 


(numerator (/ 6 4)) 
(denominator (/ 6 4)) 
(denominator 

(exact->inexact (/ 6 4))) 


3 

2 

2.0 


(floor x) 
(ceiling x) 
(truncate x ) 
(round x) 


essential procedure 
essential procedure 
essential procedure 
essential procedure 


These procedures return integers. Floor returns the 
largest integer not larger than x. Ceiling returns the 
smallest integer not smaller than x. Truncate returns the 
integer closest to x whose absolute value is not larger than 
the absolute value of x. Round returns the closest inte¬ 
ger to x, rounding to even when x is halfway between two 
integers. 

Rationale: Round rounds to even for consistency with the de¬ 
fault rounding mode specified by the IEEE floating point stan¬ 
dard. 


Note: If the argument to one of these procedures is inexact, 
then the result will also be inexact. If an exact value is needed, 
the result should be passed to the inexact->exact procedure. 

(floor -4.3) 

(ceiling -4.3) 

(truncate -4.3) 

(round -4.3) 


=> -5.0 

=> -4.0 

==> -4.0 

=» -4.0 


(floor 3,5) 
(ceiling 3.5) 
(truncate 3.5) 
(round 3.5) 


3.0 

4.0 

3.0 

4.0 ; inexact 


(round 7/2) 
(round 7) 


4 ; exact 

7 


(rationalize x y) 


procedure 


Rationalize returns the simplest rational number differ¬ 
ing from x by no more than y. A rational number r x is 
simpler than another rational number r 2 if r x = pi/qi and 
r 2 = P 2/22 (in lowest terms) and |p x | < |p 2 | and |g x | < |g 2 |. 
Thus 3/5 is simpler than 4/7. Although not all rationals 
are comparable in this ordering (consider 2/7 and 3/5) any 
interval contains a rational number that is simpler than ev¬ 
ery other rational number in that interval (the simpler 2/5 
lies between 2/7 and 3/5). Note that 0 = 0/1 is the sim¬ 
plest rational of all. 

(rationalize 

(inexact->exact .3) 1/10) => 1/3 ; exact 

(rationalize .3 1/10) =► #il/3 ; inexact 
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(exp z ) 
(log z ) 
(sin z) 
(cos z ) 
(tan z) 
(asin z) 
(acos z) 
(atan z) 
(atan y x ) 


procedure 

procedure 

procedure 

procedure 

procedure 

procedure 

procedure 

procedure 

procedure 


These procedures are part of every implementation that 
supports general real numbers; they compute the usual 
transcendental functions. Log computes the natural log¬ 
arithm of z (not the base ten logarithm). Asin, acos, 
and atan compute arcsine (sin -1 ), arccosine (cos -1 ), and 
arctangent (tan -1 ), respectively. The two-argument vari¬ 
ant of atan computes (angle (make-rectangular a y)) 
(see below), even in implementations that don’t support 
general complex numbers. 


In general, the mathematical functions log, arcsine, arcco¬ 
sine, and arctangent are multiply defined. For nonzero real 
x, the value of log a; is defined to be the one whose imagi¬ 
nary part lies in the range —i r (exclusive) to 7r (inclusive). 
logO is undefined. The value of logz when z is complex is 
defined according to the formula 

logz = logmagnitude(z) + i angle(z) 

With log defined this way, the values of sin -1 z, cos -1 z, 
and tan -1 z are according to the following formulae: 

sin -1 z = —i\og{iz + \f\ — z 2 ) 
cos -1 z = 7t/2 — sin -1 z 


tan -1 z = (log(l -f iz) — log(l - iz))/(2i) 


The above specification follows [83], which in turn 
cites [60]; refer to these sources for more detailed discussion 
of branch cuts, boundary conditions, and implementation 
of these functions. When it is possible these procedures 
produce a real result from a real argument. 


(sqrt z) procedure 

Returns the principal square root of z. The result will have 
either positive real part, or zero real part and non-negative 
imaginary part. 


(expt zi Z2 ) 

Returns z% raised to the power Z2: 

Zl * 3 = e Z2l ° SZl 

0° is defined to be equal to 1. 


(make-rectangular xi X2 ) 
(make-polar *3 X4 ) 
(real-part z) 


procedure 


procedure 

procedure 

procedure 


(imag-part z) procedure 

(magnitude z) procedure 

(angle z) procedure 

These procedures are part of every implementation that 
supports general complex numbers. Suppose x\, X2, £3, 
and X4 are real numbers and z is a complex number such 
that 

z = Xi + X2i = £3 • e lXA 

Then make-rectangular and make-polar return z, 
real-part returns x%, imag-part returns X2, magnitude 
returns £3, and angle returns £4. In the case of angle, 
whose value is not uniquely determined by the preceding 
rule, the value returned will be the one in the range —tt 
(exclusive) to n (inclusive). 

Rationale: Magnitude is tlie same as abs for a real argu¬ 

ment, but abs must be present in all implementations, whereas 
magnitude need only be present in implementations that sup¬ 
port general complex numbers. 


(exact->inexact z) procedure 

(inexact->exact z) procedure 

Exact->inexact returns an inexact representation of z. 
The value returned is the inexact number that is numeri¬ 
cally closest to the argument. If an exact argument has no 
reasonably close inexact equivalent, then a violation of an 
implementation restriction may be reported. 

Inexact->exact returns an exact representation of z. The 
value returned is the exact number that is numerically clos¬ 
est to the argument. If an inexact argument has no rea¬ 
sonably close exact equivalent, then a violation of an im¬ 
plementation restriction may be reported. 

These procedures implement the natural one-to-one corre¬ 
spondence between exact and inexact integers throughout 
an implementation-dependent range. See section 6.5.3. 


6.5.6. Numerical input and output 


(number->string number) essential procedure 

(number->string number radix ) essential procedure 

Radix must be an exact integer, either 2, 8, 10, or 16. If 
omitted, radix defaults to 10. The procedure number-> 
string takes a number and a radix and returns as a string 
an external representation of the given number in the given 
radix such that 


(let ((number number) 

(radix radix)) 

(eqv? number 

(string->number (number->string number 

radix) 


radix))) 
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is true. It is an error if no possible result makes this ex¬ 
pression true. 

If number is inexact, the radix is 10, and the above ex¬ 
pression can be satisfied by a result that contains a deci¬ 
mal point, then the result contains a decimal point and is 
expressed using the minimum number of digits (exclusive 
of exponent and trailing zeroes) needed to make the above 
expression true [89, 10]; otherwise the format of the result 
is unspecified. 

The result returned by number->string never contains an 
explicit radix prefix. 

Note: The error case can occur only when number is not a 
complex number or is a complex number with a non-rational 
real or imaginary part. 

Rationale: If number is an inexact number represented us¬ 

ing flonums, and the radix is 10, then the above expression is 
normally satisfied by a result containing a decimal point. The 
unspecified case allows for infinities, NaNs, and non-flonum rep¬ 
resentations. 


(string->number string) essential procedure 

(string->mimber string radix) essential procedure 

Returns a number of the maximally precise representation 
expressed by the given string. Radix must be an exact 
integer, either 2, 8, 10, or 16. If supplied, radix is a default 
radix that may be overridden by an explicit radix prefix in 
string (e.g. "#ol77"). If radix is not supplied, then the 
default radix is 10. If string is not a syntactically valid 
notation for a number, then string->number returns #f . 


(string->number "100") 
(string->number "100" 16) 
(string->number "le2") 
(string->nuitiber "15##") 


100 

256 

100.0 

1500.0 


Note: Although string->number is an essential procedure, an 
implementation may restrict its domain in the following ways. 
String->nuinberis permitted to return #f whenever string con¬ 
tains an explicit radix prefix. If all numbers supported by an 
implementation are real, then string->number is permitted to 
return #f whenever string uses the polar or rectangular nota¬ 
tions for complex numbers. If all numbers are integers, then 
string->number may return #f whenever the fractional nota¬ 
tion is used. If all numbers are exact, then string->number 
may return #f whenever an exponent marker or explicit exact¬ 
ness prefix is used, or if a # appears in place of a digit. If all 
inexact numbers are integers, then string->number may return 
#f whenever a decimal point is used. 


6.6. Characters 


notation #\{character) or #\{character name). For exam¬ 
ple: 


#\a 
#\A 
#\( 

#\ 

#\space 

#\newline 


; lower case letter 
; upper case letter 
; left parenthesis 
; the space character 
; the preferred way to write a space 
; the newline character 


Case is significant in #\{character), but not in 
#\(character name). If (character) in #\(character) is al¬ 
phabetic, then the character following (character) must be 
a delimiter character such as a space or parenthesis. This 
rule resolves the ambiguous case where, for example, the se¬ 
quence of characters “#\space” could be taken to be either 
a representation of the space character or a representation 
of the character “#\s” followed by a representation of the 
symbol “pace.” 

Characters written in the #\ notation are self-evaluating. 
That is, they do not have to be quoted in programs. 

Some of the procedures that operate on characters ignore 
the difference between upper case and lower case. The pro¬ 
cedures that ignore case have “-ci” (for “case insensitive”) 
embedded in their names. 


(char? obj) essential procedure 

Returns #t if obj is a character, otherwise returns #f . 


(char=? chari char 2 ) 
(char<? chari char 2 ) 
(char>? chari char 2 ) 
(char<=? chari char 2 ) 
(char>=? chari cha^) 


essential procedure 
essential procedure 
essential procedure 
essential procedure 
essential procedure 


These procedures impose a total ordering on the set of 
characters. It is guaranteed that under this ordering: 


• The upper case characters are in order. For example, 
(char<? #\A #\B) returns #t. 

• The lower case characters are in order. For example, 
(char<? #\a #\b) returns #t. 

• The digits are in order. For example, (char<? #\0 
#\ 9 ) returns #t. 

• Either all the digits precede all the upper case letters, 
or vice versa. 


Characters are objects that represent printed characters 
such as letters and digits. Characters are written using the 


Either all the digits precede all the lower case letters, 
or vice versa. 
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Some implementations may generalize these procedures to 
take more than two arguments, as with the corresponding 
numerical predicates. 


(char-ci=? char\ char 2 ) 
(char-ci<? char\ char 2 ) 
(char-ci>? char\ char 2 ) 
(char-ci<=? char% chari) 
(char-ci>=? chari char 2 ) 


essential procedure 
essential procedure 
essential procedure 
essential procedure 
essential procedure 


These procedures are similar to char=? et cetera, but they 
treat upper case and lower case letters as the same. For 
example, (char-ci=? #\A #\a) returns #t. Some imple¬ 
mentations may generalize these procedures to take more 
than two arguments, as with the corresponding numerical 
predicates. 


(char-alphabetic? char) 
(char-numeric? char) 
(char-whitespace? char) 
(char-upper-case? letter) 
(char-lower-case? letter) 


essential procedure 
essential procedure 
essential procedure 
essential procedure 
essential procedure 


These procedures return #t if their arguments are alpha¬ 
betic, numeric, whitespace, upper case, or lower case char¬ 
acters, respectively, otherwise they return #f. The follow¬ 
ing remarks, which are specific to the ASCII character set, 
are intended only as a guide: The alphabetic characters are 
the 52 upper and lower case letters. The numeric charac¬ 
ters are the ten decimal digits. The whitespace characters 
are space, tab, line feed, form feed, and carriage return. 


(char->integer char) essential procedure 

(integer->char n) essential procedure 

Given a character, char->integer returns an exact inte¬ 
ger representation of the character. Given an exact inte¬ 
ger that is the image of a character under char->integer, 
integer->char returns that character. These procedures 
implement injective order isomorphisms between the set of 
characters under the char<=? ordering and some subset of 
the integers under the <= ordering. That is, if 

(char<=? a h) => #t and (<= x y) =$■ #t 
and x and y are in the domain of integer->char, then 

(<= (char->integer a) 

(char->integer b)) =$• #t 

(char<=? (integer->char x) 

(integer->char y )) ==> #t 


(char-upcase char) essential procedure 

(char-downcase char) essential procedure 

These procedures return a character char 2 such that 
(char-ci=? char char 2 ). In addition, if char is alpha¬ 
betic, then the result of char-upcase is upper case and 
the result of char-downcase is lower case. 


6.7. Strings 

Strings are sequences of characters. Strings are written 
as sequences of characters enclosed within doublequotes 
("). A doublequote can be written inside a string only by 
escaping it with a backslash (\), as in 

"The word V'recursionV has many meanings." 

A backslash can be written inside a string only by escaping 
it with another backslash. Scheme does not specify the 
effect of a backslash within a string that is not followed by 
a doublequote or backslash. 

A string constant may continue from one line to the next, 
but the exact contents of such a string are unspecified. 

The length of a string is the number of characters that 
it contains. This number is a non-negative integer that 
is fixed when the string is created. The valid, indexes of 
a string are the exact non-negative integers less than the 
length of the string. The first character of a string has 
index 0, the second has index 1, and so on. 

In phrases such as “the characters of string beginning with 
index start and ending with index end,” it is understood 
that the index start is inclusive and the index end is ex¬ 
clusive. Thus if start and end are the same index, a null 
substring is referred to, and if start is zero and end is the 
length of string, then the entire string is referred to. 

Some of the procedures that operate on strings ignore the 
difference between upper and lower case. The versions that 
ignore case have “-ci” (for “case insensitive”) embedded 
in their names. 

(string? obj) essential procedure 

Returns #t if obj is a string, otherwise returns #1. 

(make-string k) essential procedure 

(make-string k char) essential procedure 

Make-string returns a newly allocated string of length k. 
If char is given, then all elements of the string are ini¬ 
tialized to char, otherwise the contents of the string are 
unspecified. 

(string char ...) essential procedure 

Returns a newly allocated string composed of the argu¬ 
ments. 

(string-length string) essential procedure 

Returns the number of characters in the given string. 

(string-ref string k) essential procedure 

k must be a valid index of string. String-ref returns 
character k of string using zero-origin indexing. 
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(string-set! string k char ) essential procedure 

k must be a valid index of string. String-set! stores char 
in element k of string and returns an unspecified value. 

(define (f) (make-string 3 #\*)) 

(define (g) "***") 

(string-set! (f) 0 #\?) => unspecified 

(string-set! (g) 0 #\?) =£■ error 

(string-set! (symbol->string ’immutable) 

0 

#\?) =£- error 


(string->list string ) essential procedure 

(list->string chars ) essential procedure 

String->list returns a newly allocated list of the charac¬ 
ters that make up the given string. List->string returns 
a newly allocated string formed from the characters in the 
list chars. String->list and list->string are inverses 
so far as equal? is concerned. 

(string-copy string) procedure 

Returns a newly allocated copy of the given string. 


(string=? stringi string 2 ) essential procedure 

(string-ci=? stringi strings ) essential procedure 

Returns #t if the two strings are the same length and con¬ 
tain the same characters in the same positions, otherwise 
returns #f. String-ci=? treats upper and lower case let¬ 
ters as though they were the same character, but string=? 
treats upper and lower case as distinct characters. 


(string<? stringi string 2 ) 
(string>? stringi string 2 ) 
(string<=? stringi string 2 ) 
(string>=? stringi string 2 ) 
(string-ci<? stringi string 2 ) 
(string-ci>? stringi string 2 ) 
(string-ci<=? stringi string) 
(string-ci>=? stringi string 2 ) 


essential procedure 
essential procedure 
essential procedure 
essential procedure 
essential procedure 
essential procedure 
essential procedure 
essential procedure 


These procedures are the lexicographic extensions to 
strings of the corresponding orderings on characters. For 
example, string<? is the lexicographic ordering on strings 
induced by the ordering char<? on characters. If two 
strings differ in length but are the same up to the length 
of the shorter string, the shorter string is considered to be 
lexicographically less than the longer string. 


Implementations may generalize these and the string=? 
and string-ci=? procedures to take more than two argu¬ 
ments, as with the corresponding numerical predicates. 


(substring string start end) essential procedure 

String must be a string, and start and end must be exact 
integers satisfying 

0 < start < end < (string-length string). 

Substring returns a newly allocated string formed from 
the characters of string beginning with index start (inclu¬ 
sive) and ending with index end (exclusive). 

(string-append string ...) essential procedure 

Returns a newly allocated string whose characters form the 
concatenation of the given strings. 


(string-fill! string char) procedure 

Stores char in every element of the given string and returns 
an unspecified value. 

6.8. Vectors 

Vectors are heterogenous structures whose elements are in¬ 
dexed by integers. A vector typically occupies less space 
than a list of the same length, and the average time re¬ 
quired to access a randomly chosen element is typically 
less for the vector than for the list. 

The length of a vector is the number of elements that it 
contains. This number is a non-negative integer that is 
fixed when the vector is created. The valid indexes of a 
vector are the exact non-negative integers less than the 
length of the vector. The first element in a vector is indexed 
by zero, and the last element is indexed by one less than 
the length of the vector. 

Vectors are written using the notation #(obj ...). For 
example, a vector of length 3 containing the number zero 
in element 0, the list (2 2 2 2) in element 1, and the 
string "Anna" in element 2 can be written as following: 

#(0 (2222) "Anna") 

Note that this is the external representation of a vector, not 
an expression evaluating to a vector. Like list constants, 
vector constants must be quoted: 

’#(0 (2222) "Anna") 

#(0 (2 2 2 2) "Anna") 


(vector? obj) essential procedure 

Returns #t if obj is a vector, otherwise returns #f. 

(make-vector k) essential procedure 

(make-vector k fill) procedure 

Returns a newly allocated vector of k elements. If a second 
argument is given, then each element is initialized to fill. 
Otherwise the initial contents of each element is unspeci¬ 
fied. 
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(vector obj ... ) essential procedure 

Returns a newly allocated vector whose elements contain 
the given arguments. Analogous to list. 

(vector ’a ’b ’c) =4 #(a b c) 


(vector-length vector) essential procedure 

Returns the number of elements in vector. 

(vector-ref vector k) essential procedure 

k must be a valid index of vector. Vector-ref returns the 
contents of element k of vector. 

(vector-ref ’#(1 1 2 3 5 8 13 21) 

5) 

=4- 8 

(vector-ref ’#(1 1 2 3 5 8 13 21) 

(inexact->exact 

(round (* 2 (acos -1))))) 

=>• 13 


(vector-set! vector k obj ) essential procedure 

k must be a valid index of vector. Vector-set ! stores obj 
in element k of vector. The value returned by vector-set! 
is unspecified. 

(let ((vec (vector 0 ’(2222) "Anna"))) 
(vector-set! vec 1 ’("Sue" "Sue")) 
vec) 

=4 #(0 ("Sue" "Sue") "Anna") 

(vector-set! ’#(0 1 2) 1 "doe") 

=4* error ; constant vector 


(vector->list vector ) essential procedure 

(list->vector list) essential procedure 

Vector->list returns a newly allocated list of the objects 
contained in the elements of vector. List~>vector returns 
a newly created vector initialized to the elements of the list 
list. 

(vector->list ’#(dah dah didah)) 

=4 (dah dah didah) 

(list->vector ’(dididit dah)) 

=4- # (dididit dah) 


(vector-fill! vector fill) procedure 

Stores fill in every element of vector. The value returned 
by vector-fill! is unspecified. 


6.9. Control features 

This chapter describes various primitive procedures which 
control the flow of program execution in special ways. The 
procedure? predicate is also described here. 

(procedure? obj) essential procedure 

Returns #t if obj is a procedure, otherwise returns #f . 

(procedure? car) =4 #t 

(procedure? ’car) =4> #f 

(procedure? (lambda (x) (* x x))) 

=4- #t 

(procedure? ’(lambda (x) (* x x))) 

=4 #f 

(call-with-current-continuation procedure?) 

=4> #t 

(apply proc args) essential procedure 

(apply proc argi ... args) procedure 

Proc must be a procedure and args must be a list. The 
first (essential) form calls proc with the elements of args as 
the actual arguments. The second form is a generalization 
of the first that calls proc with the elements of the list 
(append (list arg\ ...) args) as the actual arguments. 

(apply + (list 3 4)) =4 ? 

(define compose 
(lambda (f g) 

(lambda args 

(f (apply g args))))) 

((compose sqrt *) 12 75) =4- 30 

(map proc lisfi Ust 2 . ■. ) essential procedure 

The lists must be lists, and proc must be a procedure taking 
as many arguments as there are lists. If more than one list 
is given, then they must all be the same length. Map applies 
proc element-wise to the elements of the lists and returns a 
list of the results, in order from left to right. The dynamic 
order in which proc is applied to the elements of the lists 
is unspecified. 

(map cadr ’((a b) (d e) (g h))) 

=4- (b e h) 

(map (lambda (n) (expt n n)) 

’(1234 5)) 

=4 (1 4 27 256 3125) 

(map + ’(1 2 3) ’(4 5 6)) =4 (5 7 9) 

(let ((count 0)) 

(map (lambda (ignored) 

(set! count (+ count 1)) 
count) 

’(a b c))) 


unspecified 
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(for-each proc list\ list 2 ...) essential procedure 

The arguments to for-each are like the arguments to map, 
but for-each calls proc for its side effects rather than for 
its values. Unlike map, for-each is guaranteed to call proc 
on the elements of the lists in order from the first element to 
the last, and the value returned by for-each is unspecified. 

(let ((v (make-vector 5))) 

(for-each (lambda (i) 

(vector-set! v i (* i i))> 

’(0123 4)) 

v) =>#(0 14 9 16) 

(force promise) procedure 

Forces the value of promise (see delay, section 4.2.5). If no 
value has been computed for the promise, then a value is 
computed and returned. The value of the promise is cached 
(or “memoized”) so that if it is forced a second time, the 
previously computed value is returned. 

(force (delay (+ 1 2))) => 3 

(let ((p (delay (+ 1 2)))) 

(list (force p) (force p))) 

=4- (3 3) 

(define a-stream 
(letrec ((next 

(lambda (n) 

(cons n (delay (next (+ n 1))))))) 

(next 0))) 

(define head car) 

(define tail 

(lambda (stream) (force (cdr stream)))) 

(head (tail (tail a-stream))) 

Force and delay are mainly intended for programs written 
in functional style. The following examples should not be 
considered to illustrate good programming style, but they 
illustrate the property that only one value is computed for 
a promise, no matter how many times it is forced. 

(define count 0) 

(define p 

(delay (begin (set! count (+ count 1)) 

(if (> count x) 
count 

(force p))))) 

(define x 5) 

p => a promise 

(force p) ==> 6 

p => a promise, still 

(begin (set! x 10) 

(force p)) => 6 

Here is a possible implementation of delay and force. 
Promises are implemented here as procedures of no argu¬ 
ments, and force simply calls its argument: 


(define force 
(lambda (object) 

(object))) 

We define the expression 
(delay (expression) ) 

to have the same meaning as the procedure call 

(make-promise (lambda () (expression))), 

where make-promise is defined as follows: 

(define make-promise 
(lambda (proc) 

(let ((result-ready? #f) 

(result #f)) 

(lambda () 

(if result-ready? 
result 

(let ((x (proc))) 

(if result-ready? 
result 

(begin (set! result-ready? #t) 
(set! result x) 
result)))))))) 

Rationale: A promise may refer to its own value, as in the 
last example above. Forcing such a promise may cause the 
promise to be forced a second time before the value of the first 
force has been computed. This complicates the definition of 
make-promise. 

Various extensions to this semantics of delay and force 
are supported in some implementations: 

• Calling force on an object that is not a promise may 
simply return the object. 

• It may be the case that there is no means by which 
a promise can be operationally distinguished from its 
forced value. That is, expressions like the following 
may evaluate to either #t or to #f, depending on the 
implementation: 

(eqv? (delay 1) 1) => unspecified 

(pair? (delay (cons 1 2))) ==> unspecified 

• Some implementations may implement “implicit forc¬ 
ing,” where the value of a promise is forced by primi¬ 
tive procedures like cdr and +: 

(+ (delay (* 3 7)) 13) =k 34 

(call-with-current-continuation proc) 

essential procedure 

Proc must be a procedure of one argument. The procedure 
call-with-current-continuation packages up the cur¬ 
rent continuation (see the rationale below) as an “escape 
procedure” and passes it as an argument to proc. The 
escape procedure is a Scheme procedure of one argument 
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that, if it is later passed a value, will ignore whatever con¬ 
tinuation is in effect at that later time and will give the 
value instead to the continuation that was in effect when 
the escape procedure was created. 

The escape procedure that is passed to proc has unlimited 
extent just like any other procedure in Scheme. It may be 
stored in variables or data structures and may be called as 
many times as desired. 

The following examples show only the most common 
uses of call-with-current-continuation. If all real 
programs were as simple as these examples, there 
would be no need for a procedure with the power of 
call-with-current-continuation. 

(call-with-current-continuation 
(lambda (exit) 

(for-each (lambda (x) 

(if (negative? x) 

(exit x))) 

’(54 0 37 -3 245 19)) 

#t)) =>• -3 

(define list-length 
(lambda (obj) 

(call-with-current-continuation 
(lambda (return) 

(letrec ((r 

(lambda (obj) 

(cond ((null? obj) 0) 

((pair? obj) 

(+ (r (cdr obj)) 1)) 
(else (return #f)))))) 

(r obj)))))) 

(list-length ’(1 2 3 4)) =$• 4 

(list-length ’ (a b . c)) =4- #f 

Rationale: 

A common use of call-with-current-continuation is for 
structured, non-local exits from loops or procedure bodies, but 
in fact call-with-current-continuation is extremely useful 
for implementing a wide variety of advanced control structures. 

Whenever a Scheme expression is evaluated there is a contin¬ 
uation wanting the result of the expression. The continuation 
represents an entire (default) future for the computation. If the 
expression is evaluated at top level, for example, then the con¬ 
tinuation might take the result, print it on the screen, prompt 
for the next input, evaluate it, and so on forever. Most of the 
time the continuation includes actions specified by user code, 
as in a continuation that will take the result, multiply it by 
the value stored in a local variable, add seven, and give the 
answer to the top level continuation to be printed. Normally 
these ubiquitous continuations are hidden behind the scenes and 
programmers don’t think much about them. On rare occasions, 
however, a programmer may need to deal with continuations ex¬ 
plicitly. Call-with-current-continuation allows Scheme pro¬ 
grammers to do that by creating a procedure that acts just like 
the current continuation. 


Most programming languages incorporate one or more special- 
purpose escape constructs with names like exit, return, or 
even goto. In 1965, however, Peter Landin [55] invented a 
general purpose escape operator called the J-operator. John 
Reynolds [69] described a simpler but equally powerful con¬ 
struct in 1972. The catch special form described by Sussman 
and Steele in the 1975 report on Scheme is exactly the same as 
Reynolds’s construct, though its name came from a less general 
construct in Maclisp. Several Scheme implementors noticed 
that the full power of the catch construct could be provided by 
a procedure instead of by a special syntactic construct, and the 
name call-with-current-continuation was coined in 1982. 
This name is descriptive, but opinions differ on the merits of 
such a long name, and some people use the name call/cc in¬ 
stead. 

6.10. Input and output 
6.10.1. Poi'ts 

Ports represent input and output devices. To Scheme, an 
input port is a Scheme object that can deliver characters 
upon command, while an output port is a Scheme object 
that can accept characters. 

(call-with-input-file string proc) 

essential procedure 

(call-with-output-file string proc) 

essential procedure 

Proc should be a procedure of one argument, and 
string should be a string naming a file. For 

call-with-input-f ile, the file must already exist; for 
call-with-output-f ile, the effect is unspecified if the 
file already exists. These procedures call proc with one ar¬ 
gument: the port obtained by opening the named file for 
input or output. If the file cannot be opened, an error is 
signalled. If the procedure returns, then the port is closed 
automatically and the value yielded by the procedure is re¬ 
turned, If the procedure does not return, then the port will 
not be closed automatically unless it is possible to prove 
that the port will never again be used for a read or write 
operation. 

Rationale: Because Scheme’s escape procedures have un¬ 

limited extent, it is possible to escape from the current con¬ 
tinuation but later to escape back in. If implementations 
were permitted to close the port on any escape from the 
current continuation, then it would be impossible to write 
portable code using both call-with-current-continuation 
and call-with-input-file or call-with-output-file. 

(input-port? obj) essential procedure 

(output-port? obj) essential procedure 

Returns #t if obj is an input port or output port respec¬ 
tively, otherwise returns #f. 
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(current-input-port) essential procedure 

(current-output-port) essential procedure 

Returns the current default input or output port. 

(with-input-from-file string thunk) procedure 

(with-output-to-file string thunk) procedure 

Thunk must be a procedure of no arguments, and 
string must be a string naming a file. For 

with-input-from-file, the file must already exist; for 
with-output-to-file, the effect is unspecified if the file 
already exists. The file is opened for input or out¬ 
put, an input or output port connected to it is made 
the default value returned by current-input-port or 
current-output-port, and the thunk is called with no ar¬ 
guments. When the thunk returns, the port is closed and 
the previous default is restored. With-input-from-file 
and with-output-to-f ile return the value yielded by 
thunk. If an escape procedure is used to escape from the 
continuation of these procedures, their behavior is imple¬ 
mentation dependent. 

(open-input-file filename) essential procedure 

Takes a string naming an existing file and returns an input 
port capable of delivering characters from the file. If the 
file cannot be opened, an error is signalled. 

(open-output-file filename) essential procedure 

Takes a string naming an output file to be created and 
returns an output port capable of writing characters to a 
new file by that name. If the file cannot be opened, an 
error is signalled. If a file with the given name already 
exists, the effect is unspecified. 

(close-input-port port) essential procedure 

(close-output-port port) essential procedure 

Closes the file associated with port, rendering the port in¬ 
capable of delivering or accepting characters. These rou¬ 
tines have no effect if the file has already been closed. The 
value returned is unspecified. 

6.10.2. Input 

(read) essential procedure 

(read port) essential procedure 

Read converts external representations of Scheme objects 
into the objects themselves. That is, it is a parser for the 
nonterminal (datum) (see sections 7.1.2 and 6.3). Read 
returns the next object parsable from the given input port, 
updating port to point to the first character past the end 
of the external representation of the object. 


If an end of file is encountered in the input before any char¬ 
acters are found that can begin an object, then an end of 
file object is returned. The port remains open, and fur¬ 
ther attempts to read will also return an end of file object. 
If an end of file is encountered after the beginning of an 
object’s external representation, but the external represen¬ 
tation is incomplete and therefore not parsable, an error is 
signalled. 

The port argument may be omitted, in which case it de¬ 
faults to the value returned by current-input-port. It is 
an error to read from a closed port. 

(read-char) essential procedure 

(read-char port) essential procedure 

Returns the next character available from the input port, 
updating the port to point to the following character. If 
no more characters are available, an end of file object is 
returned. Port may be omitted, in which case it defaults 
to the value returned by current-input-port. 

(peek-char) essential procedure 

(peek-char port) essential procedure 

Returns the next character available from the input port, 
without updating the port to point to the following char¬ 
acter. If no more characters are available, an end of file 
object is returned. Port may be omitted, in which case it 
defaults to the value returned by current-input-port. 

Note: The value returned by a call to peek-char is the same as 
the value that would have been returned by a call to read-char 
with the same port. The only difference is that the very next call 
to read-char or peek-char on that port will return the value 
returned by the preceding call to peek-char. In particular, a 
call to peek-char on an interactive port will hang waiting for 
input whenever a call to read-char would have hung. 

(eof-object? obj) essential procedure 

Returns #t if obj is an end of file object, otherwise returns 
#f. The precise set of end of file objects will vary among 
implementations, but in any case no end of file object will 
ever be an object that can be read in using read. 

(char-ready?) procedure 

(char-ready? port) procedure 

Returns #t if a character is ready on the input port and 
returns #f otherwise. If char-ready returns #t then the 
next read-char operation on the given port is guaranteed 
not to hang. If the port is at end of file then char-ready? 
returns #t. Port may be omitted, in which case it defaults 
to the value returned by current-input-port. 

Rationale: Char-ready? exists to make it possible for a pro¬ 
gram to accept characters from interactive ports without getting 
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stuck waiting for input. Any input editors associated with such 
ports must ensure that characters whose existence has been as¬ 
serted by char-ready? cannot be rubbed out. If char-ready? 
were to return #f at end of file, a port at end of file would 
be indistinguishable from an interactive port that has no ready 
characters. 

6.10.3. Output 

(write obj ) essential procedure 

(write obj port ) essential procedure 

Writes a written representation of obj to the given port. 
Strings that appear in the written representation are en¬ 
closed in doublequotes, and within those strings backslash 
and doublequote characters are escaped by backslashes. 
Write returns an unspecified value. The port argument 
may be omitted, in which case it defaults to the value re¬ 
turned by current-output-port. 

(display obj) essential procedure 

(display obj port ) essential procedure 

Writes a representation of obj to the given port. Strings 
that appear in the written representation are not enclosed 
in doublequotes, and no characters are escaped within 
those strings. Character objects appear in the represen¬ 
tation as if written by write-char instead of by write. 
Display returns an unspecified value. The port argument 
may be omitted, in which case it defaults to the value re¬ 
turned by current-output-port. 

Rationale: Write is intended for producing machine-readable 
output and display is for producing human-readable output. 
Implementations that allow “slashification” within symbols will 
probably want write but not display to slashify funny charac¬ 
ters in symbols. 

(newline) essential procedure 

(newline port) essential procedure 

Writes an end of line to port. Exactly how this is done 
differs from one operating system to another. Returns 
an unspecified value. The port argument may be omit¬ 
ted, in which case it defaults to the value returned by 

current-output-port. 

(write-char char) essential procedure 

(write-char char port) essential procedure 

Writes the character char (not an external representa¬ 
tion of the character) to the given port and returns an 
unspecified value. The port argument may be omit¬ 
ted, in which case it defaults to the value returned by 

current-output-port. 


6.10.4. System interface 

Questions of system interface generally fall outside of the 
domain of this report. However, the following operations 
are important enough to deserve description here. 

(load filename) essential procedure 

Filename should be a string naming an existing file con¬ 
taining Scheme source code. The load procedure reads ex¬ 
pressions and definitions from the file and evaluates them 
sequentially. It is unspecified whether the results of the 
expressions are printed. The load procedure does not 
affect the values returned by current-input-port and 
current-output-port. Load returns an unspecified value. 

Rationale: For portability, load must operate on source files. 
Its operation on other kinds of files necessarily varies among 
implementations. 

(transcript-on filename) procedure 

(transcript-off) procedure 

Filename must be a string naming an output file to be cre¬ 
ated. The effect of transcript-on is to open the named 
file for output, and to cause a transcript of subsequent 
interaction between the user and the Scheme system to 
be written to the file. The transcript is ended by a call 
to transcript-off, which closes the transcript file. Only 
one transcript may be in progress at any time, though some 
implementations may relax this restriction. The values re¬ 
turned by these procedures are unspecified. 
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7. Formal syntax and semantics 

This chapter provides formal descriptions of what has al¬ 
ready been described informally in previous chapters of this 
report. 

7.1. Formal syntax 

This section provides a formal syntax for Scheme written 
in an extended BNF. The syntax for the entire language, 
including features which are not essential, is given here. 

All spaces in the grammar are for legibility. Case is insignif¬ 
icant; for example, #xiA and #Xla are equivalent, (empty) 
stands for the empty string. 

The following extensions to BNF are used to make the de¬ 
scription more concise: (thing)* means zero or more occur¬ 
rences of (thing); and (thing) 4- means at least one (thing). 

7.1.1. Lexical structure 

This section describes how individual tokens (identifiers, 
numbers, etc.) are formed from sequences of characters. 
The following sections describe how expressions and pro¬ 
grams are formed from sequences of tokens. 

(Intertoken space) may occur on either side of any token, 
but not within a token. 

Tokens which require implicit termination (identifiers, 
numbers, characters, and dot) may be terminated by any 
(delimiter), but not necessarily by anything else. 

(token) —*■ (identifier) | (boolean) | (number) 

| (character) | (string) 

I ( I ) I #( I ; l ' l . I ,« I • 

(delimiter) —* (whitespace) | ( | ) | " | ; 
(whitespace) —> (space or newline) 

(comment) —>■ ; (all subsequent characters up to a 
line break) 

(atmosphere) —*■ (whitespace) j (comment) 

(intertoken space) —► (atmosphere)* 

(identifier) —» (initial) (subsequent)* 

| (peculiar identifier) 

(initial) —* (letter) | (special initial) 

(letter) —► a | b | c | ... | z 

(special initial) —* ! | $ | */, | & | * | / | : | < | = 

I > I ? I - I - I ; 

(subsequent) —> (initial) | (digit) 

| (special subsequent) 

(digit) —>0|1|2|3|4|5|6|7|8|9 
(special subsequent) —» . | + | - 
(peculiar identifier) —*• + | - | ... 

(syntactic keyword) —» (expression keyword) 

| else | => | define 
| unquote | unquote-splicing 
(expression keyword) —> quote | lambda | if 


| set! [ begin | cond | and | or | case 
| let | let* | letrec | do | delay 
| quasiquote 

(variable) —»■ (any (identifier) that isn’t 

also a (syntactic keyword)) 

(boolean) —+ #t | #f 
(character) —* #\ (any character) 

| #\ (character name) 

(character name) —* space | newline 

(string) —> " (string element)* " 

(string element) —*■ (any character other than " or \) 

| \" | w 

(number) —* (num 2}| (num 8) 

| (num 10)| (num 16) 

The following rules for (num R), (complex R), (real R), 
(ureal R), (uinteger R), and (prefix R) should be repli¬ 
cated for R = 2,8,10, and 16. There are no rules for 
(decimal 2), (decimal 8), and (decimal 16), which means 
that numbers containing decimal points or exponents must 
be in decimal radix. 

(num R) —*■ (prefix R) (complex R) 

(complex R) —> (real R) | (real R) Q (real R) 

| (real R) + (ureal R) i | (real R) - (ureal R) i 
| (real R) + i | (real R) - i 
| + (ureal R) i | - (ureal R) i | + i [ - i 
(real R) —> (sign) (ureal R) 

(ureal R) —*• (uinteger R) 

| (uinteger R) / (uinteger R) 

| (decimal R) 

(decimal 10) —*■ (uinteger 10) (suffix) 

| . (digit 10) + #* (suffix) 
j (digit 10)+ . (digit 10)* #* (suffix) 

| (digit 10) + # + . #* (suffix) 

(uinteger R) —+ (digit R} + #* 

(prefix R) —> (radix R) (exactness) 

| (exactness) (radix R) 

(suffix) —+ (empty) 

| (exponent marker) (sign) (digit 10) + 

(exponent marker) —> e | s | f | d [ 1 

(sign) —» (empty) | + | - 

(exactness) —*■ (empty) | #i | #e 

(radix 2 ) —♦ #b 

(radix 8) —+ #o 

(radix 10 ) —► (empty) | #d 

(radix 16) —* #x 

(digit- 2) —+ 0 | 1 

(digit 8) —^0|1|2|3|4|5|6|7 
(digit 10) —* (digit) 
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(digit 16} —* (digit 10) | a | b | c | d | e | f 

7 . 1 . 2 . External representations 

(Datum) is what the read procedure (section 6.10.2) suc¬ 
cessfully parses. Note that any string that parses as an 
(expression) will also parse as a (datum). 

(datum) —► (simple datum) j (compound datum.) 
(simple datum) —» (boolean) | (number) 

] (character) | (string) | (symbol) 

(symbol) —*■ (identifier) 

(compound datum) —*■ (list) | (vector) 

(list) —* ((datum)*) | ((datum) + . (datum)) 

| (abbreviation) 

(abbreviation) —» (abbrev prefix) (datum) 

(abbrev prefix) —► ’ | ' j , j 
(vector) —* #((datum)*) 

7.1.3. Expressions 

(expression) —*■ (variable) 

| (literal) 

| (procedure call) 

| (lambda expression) 

| (conditional) 

| (assignment) 

| (derived expression) 

(literal) —» (quotation) | (self-evaluating) 
(self-evaluating) —> (boolean) | (number) 

| (character) | (string) 

(quotation) —> ’(datum) | (quote (datum)) 
(procedure call) —> ((operator) (operand)*) 

(operator) —* (expression) 

(operand) —* (expression) 

(lambda expression) —*■ (lambda (formals) (body)) 
(formats) —* ((variable)*) | (variable) 

| ((variable} + . (variable)) 

(body) —*■ (definition)* (sequence) 

(sequence) —* (command)* (expression) 

(command) —*• (expression) 

(conditional) —* (if (test) (consequent) (alternate)) 
(test) —» (expression) 

(consequent) —*• (expression) 

(alternate) —* (expression) | (empty) 

(assignment) —» (set! (variable) (expression)) 

(derived expression) —*■ 

(cond (cond clause) + ) 

| (cond (cond clause}* (else (sequence))) 

| (case (expression) 

(case clause) + ) 


| (case (expression) 

(case clause}* 

(else (sequence))) 

| (and (test)*) 
j (or (test)*) 

j (let ((binding spec)*) (body)) 

| (let (variable) ((binding spec)*) (body)) 

| (let* ((binding spec}*) (body)) 

| (letrec ((binding spec}*) (body)) 

| (begin (sequence)) 

| (do ((iteration spec)*) 

((test) (sequence)) 

(command)*) 

| (delay (expression)) 

| (quasiquotation) 

(cond clause) —* ((test) (sequence)) 

] ((test)) 

| ((test) => (recipient)) 

(recipient) —*■ (expression) 

(case clause) —> (((datum)*) (sequence)) 

(binding spec) —► ((variable) (expression)) 

(iteration spec) —> ((variable) (init) (step)) 

| ((variable) (init)) 

(init) —*■ (expression) 

(step) —* (expression) 

7.1.4. Quasiquotations 

The following grammar for quasiquote expressions is not 
context-free. It is presented as a recipe for generating an 
infinite number of production rules. Imagine a copy of the 
following rules for Z? = 1,2,3,.... D keeps track of the 
nesting depth. 

(quasiquotation) —* (quasiquotation 1) 

(template 0) —* (expression) 

(quasiquotation D) —*• ' (template D) 

| (quasiquote (template D)) 

(template D) —» (simple datum) 

| (list template D) 

| (vector template D) 

| (unquotation D) 

(list template D) —* ((template or splice D)*) 

| ((template or splice D) + . (template!))) 

| ’ (template D) 

| (quasiquotation D -f 1) 

(vector template D) —*• #((template or splice D)*) 
(unquotation D) —*■ , (template D — 1) 

| (unquote (template D— 1 }) 

(template or splice D) —*■ (template D) 

| (splicing unquotation D) 

(splicing unquotation D) —>• , ^(template D — 1) 

| (unquote-splicing (template D — 1)) 
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In {quasiquotation}s, a (list template D) can some¬ 
times be confused with either an {unquotation D) or 
a (splicing unquotation D ). The interpretation as an 
(unquotation) or (splicing unquotation D) takes prece¬ 
dence. 

7.1.5. Programs and definitions 

(program) —*■ (command or definition)* 

(command or definition) —► (command) [ (definition) 
(definition) —*■ (define (variable) (expression)) 

| (define ((variable) (def formats)) (body)) 

| (begin (definition)*) 

(def formals) —* (variable)* 

| (variable) + . (variable) 


If P is a program in which all variables are defined before 
being referenced or assigned, then the meaning of P is 

£J((lambda (I*) P’) (undefined) ... )| 
where I* is the sequence of variables defined in P, P' is the 
sequence of expressions obtained by replacing every defini¬ 
tion in P by an assignment, (undefined) is an expression 
that evaluates to undefined, and £ is the semantic function 
that assigns meaning to expressions. 


7.2.1. Abstract syntax 


K e Con 
I e Ide 
E e Exp 
P e Com = Exp 


constants, including quotations 
identifiers (variables) 
expressions 
commands 


7.2. Formal semantics 

This section provides a formal denotational semantics for 
the primitive expressions of Scheme and selected built-in 
procedures. The concepts and notation used here are de¬ 
scribed in [93]; the notation is summarized below: 

(...) sequence formation 

s l k fcth member of the sequence s (1-based) 
length of sequence s 

s § t concatenation of sequences s and t 
s | k drop the first k members of sequence s 
t —+ a, b McCarthy conditional “if t then a else b” 
p[x/i] substitution “p with x for i” 

x in D injection of x into domain D 

x | D projection of x to domain D 

The reason that expression continuations take sequences 
of values instead of single values is to simplify the formal 
treatment of procedure calls and to make it easy to add 
multiple return values. 

The boolean flag associated with pairs, vectors, and strings 
will be true for mutable objects and false for immutable 
objects. 

The order of evaluation within a call is unspecified. We 
mimic that here by applying arbitrary permutations per¬ 
mute and unpermute, which must be inverses, to‘the" argu¬ 
ments in a call before and after they are evaluated. This is 
not quite right since it suggests, incorrectly, that the order 
of evaluation is constant throughout a program (for any 
given number of arguments), but it is a closer approxima¬ 
tion to the intended semantics than a left-to-right evalua¬ 
tion would be. 

The storage allocator new is implementation-dependent, 
but it must obey the following axiom: if new a e L, then 
<7 (new a | L) J. 2 = false. 

The definition of K is omitted because an accurate defini¬ 
tion of tC would complicate the semantics without being 
very interesting. 


Exp —► K | I j (E 0 E*) 

| (lambda (I*) T* E 0 ) 
j (lambda (I* . I) T* E 0 ) 

| (lambda I E* Eo) 
j (if Eo Ei E 2 ) | (if Eo Ei) 
j (set! I E) 


7.2.2. Domain equations 


€ L 

locations 

e N 

natural numbers 

T = {false, true} 

booleans 

Q 

symbols 

H 

characters 

R 

numbers 

E p = L x L x T 

pairs 

E v = L* x T 

vectors 

E s =L*xT 

strings 

M = {false, true, null, u 

ndefined, unspecified} 


miscellaneous 

e F = L x (E* —+ K —► C) 

procedure values 

€ E = Q + H + R + Ep -f- E v 

+ E s + H + F 


expressed values 

€ S = L -+ (E x T) 

stores 

e U = Ide -*• L 

environments 

e C = S —► A 

command continuations 

e K = E* -*■ C 

expression continuations 

A 

answers 

X 

errors 


7.2.3. Semantic functions 

K, : Con —+ E 
£ : Exp — ► U —+ K —+ C 
£* : Exp* —U —+ K —+ C 
C : Com* -+ U -> C -> C 

Definition of K deliberately omitted. 

£[KJ = A pK . send(/CfK]) « 
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<?|IJ = A pK . hold (lookup pi) 

( single(\e . e = undefined —► 

wrong “undefined variable”, 
sende k)) 

£[(E 0 E*)] = 

A pn . £*(permute(( Eo) § E*)) 

P 

(Ae* . ((Ae* . applicate(e* j 1) (e* f 1) k) 

(unpermute e*))) 

£[ (lambda (I*) F* E 0 )] = 

A pn . Arr . 
new a e L —> 
send ((new a | L, 

Ae*«' . #e* = #1* -+ 

tievals(Xa* . (A p'. C[F*]p'(<f[E 0 ]pV)) 
(extendsp I* a*)) 
e*> 

wrong “wrong number of arguments”) 

in E) 

K 

(update (new a \L) unspecified or), 
wrong “out of memory” a 

£ [[(lambda (I* . I) F* E 0 )] = 

A pn . Xcr . 
new tr e L —+ 

send ((new u | L, 

AeV . #e* > #1* — 
tievalsrest 

(Acr* . (Xp' . C[F*]p'(£[Eo]pV)) 
(extendsp (I* § (I)) a*)) 
e* 

(#1*), 

wrong “too few arguments”) in E) 

K 

(update (new a \ L) unspecifiedcr), 
wrong “out of memory” cr 

<f[(lambda I F* Eo)] = ^[(lambda (. I) F* Eo)] 

[(if Eo Ei E 2 )] = 

A pn . £[Eo] p (single (Xe . truishe —► £[Ei]pK, 

f[E 2 ]p«)) 

£l(if Eo Ei)] = 

A pn . f [Eo] p (single (Ae . truish e —+ £[Ei ]p«, 

send unspecified k)) 

Here and elsewhere, any expressed value other than undefined 
may be used in place of unspecified. 

£[(set! I E)] = 

Xpn . £[E] p (single(Xe . assign (lookup p I) 

e 

(send unspecified k))) 

e*n = x p k ■ k ( ) 

<f*[E 0 E*] = 

A pK . if [E 0 ] p (single(Xe 0 . <f*[E*| p (Ae* . k ((e 0 ) § e*)))) 

cn = xpe.e 

d[Fo F*] = X P e . if [F 0 ] p (Ae* . C[F*]p@) 


7,2.4. Auxiliary functions 

lookup: U —* Ide -+ L 
lookup = Apl. pi 

extends : U —► Ide* —+ L* —+ U 
extends — 

Xpi*a* . #1* = 0 — p, 

extends (p[(a* | 1)/(I* i 1)]) (I* f 1) (a* f 1) 

wrong : X —► C [implementation-dependent] 

send : E —> K —+ C 
send — Xck . n(e) 

single : (E —* C) —+ K 
single — 

Xfie* ,#e* = 1 -> il>(e * { 1), 

wrong “wrong number of return values” 

new : S —► (L + {error}) [implementation-dependent] 

hold :L-*K-+C 

hold = Xancr . send(cra } 1)k<t 

assign : L —» E —» C —► C 
assign = XaeOa . 6(update aerr) 

update : I-* E-+ S -> S 
updates Xaeo . cr[{e, true)/a] 

tievals : (L* —► C) —► E* —>■ C 
tievals = 

Xife*a . #e* = 0 —> tj)( )rr, 

new cr s L —► tievals (Xa* . rj)((new cr | L) § a*)) 

(e* f 1) 

(updatefnew cr | L)(e* J. l)cr), 
wrong “out of memory” cr 

tievalsrest: (L* —* C) —*• E* —* N —► C 
tievalsrest — 

Xij>e*v . list (dropfirst e*v) 

(single (Ae . tievals ((takefirstc*v) § (e)))) 

dropfirst= Xln . n = 0 -* l, dropfirst(l f l)(n — 1) 

takefirst= Xln . n = 0 —+ (), (l {. 1) § (takefirst(l f l)(n — 1)) 

truish : E —+ T 

truish = Ae . e = false —> false, true 

permute : Exp* —> Exp* [implementation-dependent] 

unpermute: E* —*■ E* [inverse of permute ] 

applicate: E —► E* —> K —*■ C 
applicate = 

A ee*K . e 6 F —► (e | F } 2 )e*«, wrong “bad procedure” 

onearg : (E —r K —+ C) —+ (E* —* K —► C) 
onearg — 

X Ce*« . #e* = 1 -+ C(e* l 1)k, 

wrong “wrong number of arguments” 

twoarg : (E —E —► K —*■ C) —► (E* -+ K -+ C) 
twoarg = 

X Ce*K . #e* = 2-* C(e* } l)(e* J. 2 )k, 

wrong “wrong number of arguments” 
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list : E* —» K —* C 
list — 

\e*K . #e* = 0 —>■ send null k, 

list{e* t l){single{Xe . cons(e* J. 1, c)«)) 

cons : E* —» K —> C 
cons — 

twoarg(Xcie 2 K<r . new cr e L —► 

(Ai j' . new a 1 € L —> 

send((new a | L, new a' | L, true } 
in E) 

K 

{update{new cr' [ L)e 2 <r , )> 
wrong “out of memory” cr') 
{updatefnew cr | L)ei<r), 
wrong “out of memory” a) 

less : E* —> K —► C 
less = 

twoarg^Xeie^K . (ei e R A €2 e R) —*■ 

send{e 1 | R < £2 \ R —► true, false)K, 
wrong “non-numeric argument to <”) 

add : E* —> K —► C 
add = 

twoarg(Xei€ 2 K . (ei € R A €2 e R) —► 

send((e 1 | R + £2 1 R) in E)k, 

wrong “non-numeric argument to +”) 

car : E* —» K —+ C 
car = 

onearg(XeK . e e E p —* hold{e | E p J. 1 )k, 

wrong “non-pair argument to car”) 

cdr : E* —► K —*■ C [similar to cor] 

setcar : E* —>■ K —* C 
setcar = 

twoarg{Xe\C2H . <1 6 E p -» 

(ei | E p i 3) —f assign (ei | E p | 1) 

«2 

(send unspecified k), 

wrong “immutable argument to set-car!”, 
wrong “non-pair argument to set-car!”) 

eqv : E* —» K —► C 
eqv — 

twoarg(XeiC 2 K . (ei € M A e 2 e M) —*■ 

send(e 1 | M = e 2 | M —+ true, false)! c, 

(fi e Q A £2 € Q) -+ 

send{e 1 | Q = f 2 | Q —► true, false)K, 

(fi e H A £2 € H) -> 

send (a | H = e 2 | H —*• true, false) k, 

(f 1 € E A £2 6 R) -* 

send(e 1 j R = e 2 | R —► true, false) k, 

(ei £ E p A C 2 6 E p ) —► 

send((XpiP 2 ■ {{pi J. 1) = (jp 2 J. 1)A 

(p 1 i 2) = (p 2 i 2)) —■ true, 
false ) 

(ei I Ep) 

(ea I E p )) 

K, 

(ei G E, A e 2 € E v ) —r . . . , 


(ei S E s A e 2 S E s ) —»..., 

(ci e F A e 2 e F) -+ 

send{(ei \ F j 1) = (e 2 | F J. 1) —+ true, false) 

K, 

send false k) 

apply: E* —► K —+ C 
apply = 

twoarg (Aeie 2 /c. ei e F —+ valueslist { 02 } {Xe* . applicate tie* k), 
wrong “bad procedure argument to apply”) 

valueslist: E* —» K —► C 
v alueslist — 

onearg(XeK . e € E p —» 
cdr(e) 

(Ae* . valueslist 
c* 

(Ac* . car(e){single{Xe . k((c) § e*))))), 
c = null —> k( ), 

wrong “non-list argument to values-list”) 

cwcc : E* —> K —* C [call-with-current-continuation] 

cwcc = 

onearg(XeK . c e F —► 

(A 0 . new a e L —* 
applicate e 

{{new cr | L, Ae*/c' . kc*) in E) 

K 

{update{new a | L) 
unspecified 
<*)> 

wrong “out of memory” a), 
wrong “bad procedure argument”) 

7.3. Derived expression types 

This section gives rewrite rules for the derived expression 
types. By the application of these rules, any expression 
can be reduced to a semantically equivalent expression in 
which only the primitive expression types (literal, variable, 
call, lambda, if, set!) occur. 

(cond ((test) (sequence)) 

(clause 2 ) ... ) 

= (if (test) 

(begin (sequence)) 

(cond (clause 2 ) ... )) 

(cond ((test)) 

(clause 2 ) ... ) 

= (or (test) (cond (clause 2 ) ...)) 

(cond ((test) => (recipient)) 

(clause 2 ) ... ) 

= (let ((test-result (test)) 

(thunk2 (lambda () (recipient))) 

(thunk3 (lambda 0 (cond (clauses) ...)))) 
(if test-result 

((thunk2) test-result) 

(thunk3))) 
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(cond (else (sequence))) 

= (begin (sequence)) 

(cond) 

= (some expression returning an unspecified value) 

(case (key) 

((dl ...) (sequence)) 

...) 

= (let ((key (key)) 

(thunkl (lambda 0 (sequence))) 

...) 

(cond (((memv) key ’ (dl ...)) (thunkl)) 

...)) 

(case (key) 

((dl ...) (sequence)) 

(else f1 f2 ...)) 

= (let ((key (key)) 

(thunkl (lambda () (sequence))) 

(elsethunk (lambda () fl f2 ...))) 

(cond (((memv) key ’ (dl ...)) (thunkl)) 

(else (elsethunk)))) 

where (memv) is an expression evaluating to the memv pro¬ 
cedure. 

(and) = #t 

(and (test)) s (test) 

(and (testi) (testa) •••) 

= (let ((x (testi)) 

(thunk (lambda () (and (testa) •■•)))) 

(if x (thunk) x)) 

(or) = #f 

(or (test)) = (test) 

(or (testi) (testa) ...) 

= (let ((x (testi)) 

(thunk (lambda () (or (testa) ...)))) 

(if x x (thunk))) 

(let (((variablei) (initi)) ...) 

(body)) 

= ((lambda ((variablei) ...) (body)) (initi) •••) 

(let* () (body)) 

= ((lambda () (body))) 

(let* (((variablei) (initi)) 

((variablea) (inita)) 

...) 

(body)) 

= (let (((variablei) (initi))) 

(let* (((variablea) (inita)) 

...) 

(body))) 

(letrec (((variablei) (initi)) 

...) 


(body)) 

= (let (((variablei) (undefined)) 

...) 

(let (((tempi) (initi)) 

...) 

(set! (variablei) (tempi)) 

...) 

(body)) 

where (tempi), (temp 2 ), ... are variables, distinct from 
(variablei), ..., that do not free occur in the original (init) 
expressions, and (undefined) is an expression which returns 
something that when stored in a location makes it an error 
to try to obtain the value stored in the location. (No such 
expression is defined, but one is assumed to exist for the 
purposes of this rewrite rule.) The second let expression 
in the expansion is not strictly necessary, but it serves to 
preserve the property that the (init) expressions are eval¬ 
uated in an arbitrary order. 

(begin (sequence)) 

= ((lambda () (sequence))) 

The following alternative expansion for begin does not 
make use of the ability to write more than one expres¬ 
sion in the body of a lambda expression. In any case, note 
that these rules apply only if (sequence) contains no defi¬ 
nitions. 

(begin (expression)) = (expression) 

(begin (command) (sequence)) 

= ((lambda (ignore thunk) (thunk)) 

(command) 

(lambda () (begin (sequence)))) 

The following expansion for do is simplified by the assump¬ 
tion that no (step) is omitted. Any do expression in which 
a (step) is omitted can be replaced by an equivalent do ex¬ 
pression in which the corresponding (variable) appears as 
the (step). 

(do (((variablei) (initi) (stepi)) 

...) 

((test) (sequence)) 

(commandi) .., ) 

= (letrec (((loop) 

(lambda ((variablei) ...) 

(if (test) 

(begin (sequence)) 

(begin (commandi) 

((loop) (stepi) ...)))))) 

((loop) (initi) ...)) 

where (loop) is any variable which is distinct from 
(variablei), ..., and which does not occur free in the do 
expression. 

(let (variableo) (((variablei) (initi)) ■•■) 

(body)) 

= ((letrec (((variableo) (lambda ((variablei) ■••) 
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(body)))) 

(variableo)) 

{initi) ... ) 

(delay (expression)) 

= ((make-promise) (lambda () (expression))) 

where (make-promise) is an expression evaluating to some 
procedure which behaves appropriately with respect to the 
force procedure; see section 6.9. 


NOTES 


Language changes 

This section enumerates the changes that have been made 
to Scheme since the “Revised 3 report” [68] was published. 

• Although implementations may extend Scheme, they 
must offer a syntactic mode that adds no reserved 
words and preempts no lexical conventions of Scheme. 

• Implementations may report violations of implemen¬ 
tation restrictions. 

• It is no longer specified whether the empty list counts 
as true or as false in conditional expressions. It should 
be noted that the IEEE standard for Scheme requires 
the empty list to count as true [50]. 

• The sets defined by boolean?, pair?, symbol?, 
number?, char?, string?, vector?, and procedure? 
are required to be disjoint. 

• The variables bound by a lambda, let. letrec, and 
do must not contain duplicates. 

• Nested begin expressions containing definitions are 
treated as a sequence of definitions. 

• The eqv? procedure is no longer required to be true 
of any two empty strings or two empty vectors. 

• The syntax of numerical constants has been changed, 
and the exactness implied by each syntax has been 
specified. 

• The semantics of many numerical procedures have 
been clarified. 

• Rationalize has been restricted to two arguments 
and its specification clarified. 

• The number->string and string->number proce¬ 
dures have been changed. 

• Integer->char now requires an exact integer argu¬ 
ment. 


• The specification of the force procedure has been 
weakened. The previous specification was unimple- 
mentable. 


• Variables removed: t, nil. 


• Procedures removed: approximate, last-pair. 

• Procedures added: list?, peek-char. 


♦ Syntaxes made essential: case, and, or, quasiquote. 

* Procedures made essential: 


reverse 

max 

min 

modulo 

gcd 

lcm 

floor 

ceiling 

truncate 

round 

number->string 

string->number 


char-ci=? 

char-ci<? 

char-ci>? 

char-ci<=? 

char-ci>=? 

char-alphabetic? 

char-numeric? 

char-whitespace? 

char-lower-case? 

char-upper-case? 

char-upcase 

char-downcase 


make-string 
string-set I 
string-ci=? 
string-ci<? 
string-ci>? 
string-ci<=? 
string-ci>=? 
string-append 
open-input-file 
open-output-file 
close-input-port 
close-output-port 


• Procedures required to accept more general numbers 
of arguments: append, +, *, - (one argument), / (one 
argument), =, <, >, <=, >=, map, for-each. 

• A macro facility has been added as an appendix to 
this report. 
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EXAMPLE 


Integrate-system integrates the system 

y'k = fk(yi,y2,---,Vn), k = i,...,n 
of differential equations with the method of Runge-Kutta. 

The parameter system-derivative is a function that 
takes a system state (a vector of values for the state vari¬ 
ables yi,..., y n ) and produces a system derivative (the val¬ 
ues y[,..., y' n ). The parameter initial-state provides 
an initial system state, and h is an initial guess for the 
length of the integration step. 

The value returned by integrate-system is an infinite 
stream of system states. 


(define integrate-system 

(lambda (system-derivative initial-state h) 

(let ((next (runge-kutta-4 system-derivative h))) 
(letrec ((states 

(cons initial-state 

(delay (map-streams next 

states))))) 


states)))) 


Runge-Kutta -4 takes a function, f, that produces a system 
derivative from a system state. Runge-Kutta -4 produces 
a function that takes a system state and produces a new 
system state. 

(define runge-kutta-4 
(lambda (f h) 

(let ((*h (scale-vector h)) 

(*2 (scale-vector 2)) 

(*l/2 (scale-vector (/ 1 2))) 

(*l/6 (scale-vector (/ 1 6)))) 

(lambda (y) 

;; y is a system state 
(let* ((kO (*h (f y))) 

(kl (*h (f (add-vectors y (*l/2 kO))))) 
(k2 (*h (f (add-vectors y (*l/2 kl))))) 
(k3 (*h (f (add-vectors y k2))))) 
(add-vectors y 

(*l/6 (add-vectors kO 

(*2 kl) 

(*2k2) 

k3)))))))) 


(define elementwise 
(lambda (f) 

(lambda vectors 
(generate-vector 

(vector-length (car vectors)) 

(lambda (i) 

(apply f 

(map (lambda (v) (vector-ref v i)) 
vectors))))))) 


(let ((ans (make-vector size))) 

(letrec ((loop 

(lambda (i) 

(cond ((= i size) ans) 

(else 

(vector-set! ans i (proc i)) 
(loop (+ i 1))))))) 

(loop 0))))) 

(define add-vectors (elementwise +)) 

(define scale-vector 
(lambda (s) 

(elementwise (lambda (x) (* x s))))) 

Map-streams is analogous to map: it applies its first argu¬ 
ment (a procedure) to all the elements of its second argu¬ 
ment (a stream). 

(define map-streams 
(lambda (f s) 

(cons (f (head s)) 

(delay (map-streams f (tail s)))))) 

Infinite streams are implemented as pairs whose car holds 
the first element of the stream and whose cdr holds a 
promise to deliver the rest of the stream. 

(define head car) 

(define tail 

(lambda (stream) (force (cdr stream)))) 


The following illustrates the use of integrate-system in 
integrating the system 





= v c 


which models a damped oscillator. 


(define damped-oscillator 
(lambda (R L C) 

(lambda (state) 

(let ((Vc (vector-ref state 0)) 

(II (vector-ref state 1))) 

(vector (- 0 (+ (/ Vc (* R C)) (/ II C))) 
(/ Vc L)))))> 


(define the-states 
(integrate-system 

(damped-oscillator 10000 1000 .001) 
’#(1 0 ) 

. 01 )) 


(define generate-vector 
(lambda (size proc) 
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APPENDIX: MACROS 

This appendix describes an extension to Scheme that al¬ 
lows programs to define and use new derived expression 
types. A derived expression type that has been defined 
using this extension is called a macro. 

Derived expression types introduced using this extension 
have the syntax 

((keyword) (datum)*) 

where (keyword) is an identifier that uniquely determines 
the expression type. This identifier is called the syntactic 
keyword, or simply keyword, of the macro. The number of 
the (datum)s, and their syntax, depends on the expression 
type. 

Each instance of a macro is called a use of the macro. The 
set of rules, or more generally the procedure, that specifies 
how a use of a macro is transcribed into a more primitive 
expression is called the transformer of the macro. 

The extension described here consists of three parts: 

• A set of expressions used to establish that certain iden¬ 
tifiers are macro keywords, associate them with macro 
transformers, and control the scope within which a 
macro is defined, 

• a convenient pattern language that makes it easy to 
write transformers for most macros, and 

• a compatible low-level macro facility for writing macro 
transformers that cannot be expressed by the pattern 
language. 

With this extension, there are no reserved identifiers. The 
syntactic keyword of a macro may shadow variable bind¬ 
ings, and local variable bindings may shadow keyword 
bindings. All macros defined using the pattern language 
are “hygienic” and “referentially transparent”: 

• If a macro transformer inserts a binding for an identi¬ 

fier (variable or keyword), the identifier will in effect be 
renamed throughout its scope to avoid conflicts with 
other identifiers. .... . 

• If a macro transformer inserts a free reference to an 
identifier, the reference refers to the binding that was 
visible where the transformer was specified, regardless 
of any local bindings that may surround the use of the 
macro. 

This appendix is divided into three major sections. The 
first section describes the expressions and definitions used 
to introduce macros, i.e. to bind identifiers to macro trans¬ 
formers. 

The second section describes the pattern language. This 
pattern language is sufficient to specify most macro trans¬ 
formers, including those for all the derived expression types 


from section 4.2. The primary limitation of the pattern 
language is that it is thoroughly hygienic, and thus cannot 
express macros that bind identifiers implicitly. 

The third section describes a low-level macro facility that 
could be used to implement the pattern language described 
in the second section. This low-level facility is also capable 
of expressing non-hygienic macros and other macros whose 
transformers cannot be described by the pattern language, 
and is important as an example of a more powerful facility 
that can co-exist with the high-level pattern language. 

The particular low-level facility described in the third sec¬ 
tion is but one of several low-level facilities that have been 
designed and implemented to complement the pattern lan¬ 
guage described in the second section. The design of such 
low-level macro facilities remains an active area of research, 
and descriptions of alternative low-level facilities will be 
published in subsequent documents. 

Binding syntactic keywords 

Define-syntax, let-syntax, and letrec-syntax are 
analogous to define, let, and letrec, but they bind syn¬ 
tactic keywords to macro transformers instead of binding 
variables to locations that contain values. Furthermore, 
there is no def ine-syntax analogue of the internal defini¬ 
tions described in section 5.2.2. 

Rationale: As discussed below, the syntax and scope rules 

for definitions give rise to syntactic ambiguities when syntactic 
keywords are not reserved. Further ambiguities would arise if 
def ine-syntax were permitted at the beginning of a (body), 
with scope rules analogous to those for internal definitions. 

These new expression types and the pattern language de¬ 
scribed in section 7,3 are added to Scheme by augmenting 
the BNF in section 7.1 with the following new productions. 
Note that the identifier . . . used in some of these produc¬ 
tions is not a metasymbol. 

(expression) —*■ (macro use) 

| (macro block) 

(macro use) —*■ ((keyword) (datum)*) 

(keyword) -—> (identifier) 

(macro block) —> 

(let-syntax ((syntax spec)*) (body)) 

| (letrec-syntax ((syntax spec)*) (body)) 

(syntax spec) —* ((keyword) (transformer spec)) 
(transformer spec) —> 

(syntax-rules ((identifier)*) (syntax rule)*) 
(syntax rule) —► ((pattern) (template)) 

(pattern) —» (pattern identifier) 

| ((pattern)*) 

| ((pattern) 4 " . (pattern)) 

| ((pattern)* (pattern) (ellipsis)) 
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| {pattern datum) 

(pattern datum) —*■ (vector) 

| (string) 

| (character) 

| (boolean) 

| (number) 

(template) —»■ (pattern identifier) 

| ((template element)*) 
j ((template element) - * . (template)) 

| (template datum) 

(template element) —> (template) 

| (template) (ellipsis) 

(template datum) —*■ (pattern datum) 

(pattern identifier) —* (any identifier except . . .) 
(ellipsis) —► (the identifier . . .) 

(command or definition) —> (syntax definition) 

(syntax definition) —» 

(def ine-syntax (keyword) (transformer spec)) 

| (begin (syntax definition)*) 

Although macros may expand into definitions in any con¬ 
text that permits definitions, it is an error for a definition 
to shadow a syntactic keyword whose meaning is needed 
to determine whether some definition in the group of top- 
level or internal definitions that contains the shadowing 
definition is in fact a definition, or is needed to determine 
the boundary between the group and the expressions that 
follow the group. For example, the following are errors: 

(define define 3) 

(begin (define begin list)) 

(let-syntax 

((foo (syntax-rules () 

((foo (proc args ...) body ...) 

(define proc 

(lambda (args ...) 
body ...)))))) 

(let ((x 3)) 

(foo (plus x y) (+ x y)) 

(define foo x) 

(plus foo x))) 

(let-syntax (bindings) (body)) syntax 

Syntax: (Bindings) should have the form 
(((keyword) (transformer spec)) ...) 

Each (keyword) is an identifier, each (transformer spec) 
is an instance of syntax-rules, and (body) should be a 
sequence of one or more expressions. It is an error for a 
(keyword) to appear more than once in the list of keywords 
being bound. 

Semantics: The (body) is expanded in the syntactic envi¬ 
ronment obtained by extending the syntactic environment 


of the let-syntax expression with macros whose keywords 
are the (keyword)s, bound to the specified transformers. 
Each binding of a (keyword) has (body) as its region. 

(let-syntax ((when (syntax-rules () 

((when test stmtl stmt2 ...) 
(if test 

(begin stmtl 

stmt2 ...)))))) 

(let ((if #t)) 

(when if (set! if ’now)) 

if)) ==> now 

(let ((x ’outer)) 

(let-syntax ((m (syntax-rules () ((m) x)))) 

(let ((x ’inner)) 

(m)))) ==> outer 


(letrec-syntax (bindings) (body)) syntax 

Syntax: Same as for let-syntax. 

Semantics: The (body) is expanded in the syntactic envi¬ 
ronment obtained by extending the syntactic environment 
of the letrec-syntax expression with macros whose key¬ 
words are the (keyword)s, bound to the specified trans¬ 
formers. Each binding of a (keyword) has the (bindings) 
as well as the (body) within its region, so the transformers 
can transcribe expressions into uses of the macros intro¬ 
duced by the letrec-syntax expression. 

(letrec-syntax 

((or (syntax-rules () 

((or) #f) 

((or e) e) 

((or el e2 ...) 

(let ((temp el)) 

(if temp 
temp 

(or e2 . ..))))))) 

(let ((x #f) 

(y 7) 

(temp 8) 

(let odd?) 

(if even?)) 

(or x 

(let temp) 

(if y) 

y))) =>• 7 


(define-syntax (keyword) (transformer spec)) 

Syntax: The (keyword) is an identifier, and the 

(transformer spec) should be an instance of syntax-rules. 

Semantics: The top-level syntactic environment is ex¬ 
tended by binding the (keyword) to the specified trans¬ 
former. 
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(define-syntax let* 

(syntax-rules () 

((let* () bodyl body2 ...) 

(let () bodyl body2 ...)) 

((let* ((namel vail) (name2 val2) ...) 
bodyl body2 ...) 

(let ((namel vail)) 

(let* ((name2 val2) ...) 
bodyl body2 ...))))) 


Pattern language 

(syntax-rules (literals) (syntax rule) ...) 

Syntax: (Literals) is a list of identifiers, and each 
(syntax rule) should be of the form 

((pattern) (template)) 

where the (pattern) and (template) are as in the grammar 
above. 

Semantics: An instance of syntax-rules produces a new 
macro transformer by specifying a sequence of hygienic 
rewrite rules. A use of a macro whose keyword is associated 
with a transformer specified by syntax-rules is matched 
against the patterns contained in the (syntax rule)s, be¬ 
ginning with the leftmost (syntax rule). When a match is 
found, the macro use is transcribed hygienically according 
to the template. 

Each pattern begins with the keyword for the macro. This 
keyword is not involved in the matching and is not consid¬ 
ered a pattern variable or literal identifier. 

Rationale: The scope of the keyword is determined by the 
expression or syntax definition that binds it to the associated 
macro transformer. If the keyword were a pattern variable or 
literal identifier, then the template that follows the pattern 
would be within its scope regardless of whether the keyword 
were bound by let-syntax or by letrec-syntax. 

An identifier that appears in the pattern of a (syntax rule) 
is a pattern variable, unless it is the keyword that begins 
the pattern, is listed in (literals), or is the identifier 
Pattern variables match arbitrary input elements and are 
used to refer to elements of the input in the template. It 
is an error for the same pattern variable to appear more 
than once in a (pattern). 

Identifiers that appear in (literals) are interpreted as literal 
identifiers to be matched against corresponding subforms 
of the input. A subform in the input matches a literal 
identifier if and only if it is an identifier and either both its 
occurrence in the macro expression and its occurrence in 
the macro definition have the same lexical binding, or the 
two identifiers are equal and both have no lexical binding. 

A subpattern followed by .. . can match zero or more el¬ 
ements of the input. It is an error for ... to appear in 


(literals). Within a pattern the identifier ... must follow 
the last element of a nonempty sequence of subpatterns. 

More formally, an input form F matches a pattern P if and 
only if: 

• P is a pattern variable; or 

• P is a literal identifier and F is an identifier with the 
same binding; or 

• P is a pattern list (Pj ... P n ) and F is a list of n 
forms that match Pi through P n , respectively; or 

• P is an improper pattern list (Pi P 2 ... P n . P n + 1 ) 
and F is a list or improper list of n or more forms 
that match Pi through P n , respectively, and whose 
nth “cdr” matches P„+i; or 

• P is of the form (Pi ... P n P n+ i (ellipsis)) where 
(ellipsis) is the identifier . . . and F is a proper list 
of at least n elements, the first n of which match Pi 
through P n , respectively, and each remaining element 
of F matches P n +i; or 

• P is a pattern datum and F is equal to P in the sense 
of the equal? procedure. 

It is an error to use a macro keyword, within the scope of 
its binding, in an expression that does not match any of 
the patterns. 

When a macro use is transcribed according to the template 
of the matching (syntax rule), pattern variables that occur 
in the template are replaced by the subforms they match 
in the input. Pattern variables that occur in subpatterns 
followed by one or more instances of the identifier ... are 
allowed only in subtemplates that are followed by as many 
instances of .... They are replaced in the output by all 
of the subforms they match in the input, distributed as 
indicated. It is an error if the output cannot be built up 
as specified. 

Identifiers that appear in the template but are not pattern 
variables or the identifier . . . are inserted into the output 
as literal identifiers. If a literal identifier is inserted as a 
free identifier then it refers to the binding of that identifier 
within whose scope the instance of syntax-rules appears. 
If a literal identifier is inserted as a bound identifier then 
it is in effect renamed to prevent inadvertent captures of 
free identifiers. 

(define-syntax let 
(syntax-rules () 

((let ((name val) ...) bodyl body2 ...) 
((lambda (name ...) bodyl body2 ...) 
val ...)) 

((let tag ((name val) ...) bodyl body2 ...) 
((letrec ((tag (lambda (name ...) 

bodyl body2 ...))) 


tag) 
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val ...)))) 

(define-syntax cond 

(syntax-rules (else =>) 

((cond (else resultl result2 ...)) 

(begin resultl result2 ...)) 

((cond (test => result)) 

(let ((temp test)) 

(if temp (result temp)))) 

((cond (test => result) clausel clause2 ...) 
(let ((temp test)) 

(if temp 

(result temp) 

(cond clausel clause2 ...)))) 

((cond (test)) test) 

((cond (test) clausel clause2 ...) 

(or test (cond clausel clause2 ...))) 

((cond (test resultl result2 ...)) 

(if test (begin resultl result2 ...))) 

((cond (test resultl result2 ...) 
clausel clause2 ...) 

(if test 

(begin resultl result2 ...) 

(cond clausel clause2 ...))))) 

(let ((=> #f)) 

(cond (#t => ’ok))) =^> ok 

The last example is not an error because the local variable 
=> is renamed in effect, so that its use is distinct from uses 
of the top level identifier => that the transformer for cond 
looks for. Thus, rather than expanding into 

(let ((=> #f)) 

(let ((temp #t)) 

(if temp (’ok temp)))) 

which would result in an invalid procedure call, it expands 
instead into 

(let ((=> #f>) 

(if #t (begin => ’ok))) 

A compatible low-level macro facility 

Although the pattern language provided by syntax-rules 
is the preferred way to specify macro transformers, other 
low-level facilities may be provided to specify more complex 
macro transformers. In fact, syntax-rules can itself be 
defined as a macro using the low-level facilities described 
in this section. 

The low-level macro facility described here introduces 
syntax as a new syntactic keyword analogous to quote, 
and allows a (transformer spec) to be any expression. This 
is accomplished by adding the following two productions 
to the productions in section 7.1 and in section 7.3 above. 

(expression) —> (syntax (datum)) 

(transformer spec) —* (expression) 


The low-level macro system also adds the following proce¬ 
dures: 

unwrap-syntax identifier->symbol 

identifier? generate-identifier 

free-identifier=? construct-identifier 

bound-identifier=? 

Evaluation of a program proceeds in two logical steps. First 
the program is converted into an intermediate language via 
macro-expansion, and then the result of macro expansion 
is evaluated. When it is necessary to distinguish the second 
stage of this process from the full evaluation process, it is 
referred to as “execution.” 

Syntax definitions, either lexical or global, cause an iden¬ 
tifier to be treated as a keyword within the scope of the 
binding. The keyword is associated with a transformer, 
which may be created implicitly using the pattern language 
of syntax-rules or explicitly using the low-level facilities 
described below. 

Since a transformer spec must be fully evaluated during 
the course of expansion, it is necessary to specify the en¬ 
vironment in which this evaluation takes place. A trans¬ 
former spec is expanded in the same environment as that 
in which the program is being expanded, but is executed 
in an environment that is distinct from the environment 
in which the program is executed. This execution envi¬ 
ronment distinction is important only for the resolution of 
global variable references and assignments. In what fol¬ 
lows, the environment in which transformers are executed 
is called the standard transformer environment and is as¬ 
sumed to be a standard Scheme environment. 

Since part of the task of hygienic macro expansion is to 
resolve identifier references, the fact that transformers are 
expanded in the same environment as the program means 
that identifier bindings in the program can shadow iden¬ 
tifier uses within transformers. Since variable bindings in 
the program are not available at the time the transformer is 
executed, it is an error for a transformer to reference or as¬ 
sign them. However, since keyword bindings are available 
during expansion, lexically visible keyword bindings from 
the program may be used in macro uses in a transformer. 

When a macro use is encountered, the macro transformer 
associated with the macro keyword is applied to a rep¬ 
resentation of the macro expression. The result returned 
by the macro transformer replaces the original expression 
and is expanded once again. Thus macro expansions may 
themselves be or contain macro uses. 

The syntactic representation passed to a macro transformer 
encapsulates information about the structure of the repre¬ 
sented form and the bindings of the identifiers it contains. 
These syntax objects can be traversed and examined using 
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the procedures described below. The output of a trans¬ 
former may be built up using the usual Scheme list con¬ 
structors, combining pieces of the input with new syntactic 
structures. 


(syntax (datum)) syntax 

Syntax: The (datum) may be any external representation 
of a Scheme object. 

Semantics: Syntax is the syntactic analogue of quote. It 
creates a syntactic representation of (datum) that, like an 
argument to a transformer, contains information about the 
bindings for identifiers contained in (datum). The bind¬ 
ing for an identifier introduced by syntax is the closest 
lexically visible binding. All variables and keywords intro¬ 
duced by transformers must be created by syntax. It is an 
error to insert a symbol in the output of a transformation 
procedure unless it is to be part of a quoted datum. 

(symbol? (syntax x)) => #f 

(let-syntax ((car (lambda (x) (syntax car)))) 

( (car) ’ (0))) =>- 0 

(let-syntax 
((quote-quote 

(lambda (x) (list (syntax quote) ’quote)))) 
(quote-quote)) ==> quote 

(let-syntax 
((quote-quote 

(lambda (x) (list ’quote ’quote)))) 
(quote-quote)) => error 

The second quote-quote example results in an error be¬ 
cause two raw symbols are being inserted in the output. 
The quoted quote in the first quote-quote example does 
not cause an error because it will be a quoted datum. 

(let-syntax ((quote-me 

(lambda (x) 

(list (syntax quote) x)))) 
(quote-me please)) ==> (quote-me please) 

(let ((x 0)) 

(let-syntax ((alpha (lambda (e) (syntax x)))) 
(alpha))) =£• 0 

(let ((x 0)) 

(let-syntax ((alpha (lambda (x) (syntax x)))) 
(alpha))) =$■ error 

(let-syntax ((alpha 

(let-syntax ((beta 

(syntax-rules 0 
((beta) 0 )))) 

(lambda (x) (syntax (beta)))))) 
(alpha)) => error 

The last two examples are errors because in both cases a 
lexically bound identifier is placed outside of the scope of 
its binding. In the first case, the variable x is placed outside 


its scope. In the second case, the keyword beta is placed 
outside its scope. 

(let-syntax ((alpha (syntax-rules () 

((alpha) 0 )))) 

(let-syntax ((beta (lambda (x) (alpha)))) 
(beta))) =>■ 0 

(let ((list 0)) 

(let-syntax ((alpha (lambda (x) (list 0 )))) 
(alpha))) =>■ error 

The last example is an error because the reference to list 
in the transformer is shadow'ed by the lexical binding for 
list. Since the expansion process is distinct from the exe¬ 
cution of the program, transformers cannot reference pro¬ 
gram variables. On the other hand, the previous example 
is not an error because definitions for keywords in the pro¬ 
gram do exist at expansion time. 

Note: It has been suggested that #’ (datum) and #'(datum) 
would be felicitous abbreviations for (syntax (datum)) and 
(quasisyntax (datum)), respectively, where quasisyntax, 
which is not described in this appendix, would bear the same 
relationship to syntax that quasiquote bears to quote. 


(identifier? syntax-object ) procedure 

Returns #t if syntax-object represents an identifier, other¬ 
wise returns #f. 


(identifier? (syntax x)) => #t 
(identifier? (quote x)) =$> #f 
(identifier? 3) => #f 


(unwrap-syntax syntax-object) procedure 

If syntax-object is an identifier, then it is returned un¬ 
changed. Otherwise unwrap-syntax converts the outer¬ 
most structure of syntax-object into a data object whose 
external representation is the same as that of syntax-object. 
The result is either an identifier, a pair whose car and cdr 
are syntax objects, a vector whose elements are syntax ob¬ 
jects, an empty list, a string, a boolean, a character, or a 
number. 


(identifier? (unwrap-syntax (syntax x))) 

=4> #t 

(identifier? (car (unwrap-syntax (syntax (x))))) 

=>• #t 

(unwrap-syntax (cdr (unwrap-syntax (syntax (x))))) 


(free-identifier=? idi id. 2 ) procedure 

Returns #t if the original occurrences of id\ and 
id .2 have the same binding, otherwise returns #f. 
free-identifier=? is used to look for a literal identifier 
in the argument to a transformer, such as else in a cond 
clause. A macro definition for syntax-rules would use 
free-identif ier=? to look for literals in the input. 



Appendix: Macros 45 


(free-identifier=? (syntax x) (syntax x)) 

=> #t 

(free-identifier=? (syntax x) (syntax y)) 

=» #f 

(let ((x (syntax x))) 

(free-identifier=? x (syntax x))) 

=> #f 

(let-syntax 

((alpha 

(lambda (x) 

(free-identifier=? (car (unwrap-syntax x)) 
(syntax alpha))))) 
(alpha)) ==> #f 

(letrec-syntax 
((alpha 

(lambda (x) 

(free-identifier=? (car (unwrap-syntax x)) 
(syntax alpha))))) 
(alpha)) => #t 


(bound-identifier=? id\ idi) procedure 

Returns #t if a binding for one of the two identi¬ 
fiers idi and id? would shadow free references to the 
other, otherwise returns #f. Two identifiers can be 
free-identifier=? without being bound-identif ier=? 
if they were introduced at different stages in the expan¬ 
sion process. Bound-identifier=? can be used, for ex¬ 
ample, to detect duplicate identifiers in bound-variable 
lists. A macro definition of syntax-rules would use 
bound-identifier=? to look for pattern variables from 
the input pattern in the output template. 

(bound-identifier=? (syntax x) (syntax x)) 

=> #t 

(letrec-syntax 

((alpha 

(lambda (x) 

(bound-identifier=? (car (unwrap-syntax x)) 
(syntax alpha))))) 
(alpha)) => #f 


(ident if ier->symbol id) procedure 

Returns a symbol representing the original name of id. 
Ident if ier->symbol is used to examine identifiers that 
appear in literal contexts, i.e., identifiers that will appear 
in quoted structures. 

(symbol? (identifier->symbol (syntax x))) 

#t 

(identifier->symbol (syntax x)) 

=> x 


(generate-identif ier) procedure 

(generate-identifier symbol) procedure 

Returns a new identifier. The optional argument to 
generate-identif ier specifies the symbolic name of the 
resulting identifier. If no argument is supplied the name is 
unspecified. 

Generate-identif ier is used to introduce bound iden¬ 
tifiers into the output of a transformer. Since in¬ 
troduced bound identifiers are automatically renamed, 

generate-identif ier is necessary only for distinguishing 
introduced identifiers when an indefinite number of them 
must be generated by a macro. 

The optional argument to generate-identif ier specifies 
the symbolic name of the resulting identifier. If no ar¬ 
gument is supplied the name is unspecified. The proce¬ 
dure identif ier->symbol reveals the symbolic name of 
an identifier. 

(identifier->symbol (generate-identifier ’x)) 

==>• x 

(bound-identifier=? (generate-identifier ’x) 
(generate-identifier ’x)) 

=> #f 

(define-syntax set*! 

; (set*! (<identifier> <expression>) ...) 

(lambda (x) 

(letrec 

((unwrap-exp 
(lambda (x) 

(let ((x (unwrap-syntax x))) 

(if (pair? x) 

(cons (car x) 

(unwrap-exp (cdr x))) 

x))))) 

(let ((sets (map unwrap-exp 

(cdr (unwrap-exp x))))) 

(let ((ids (map car sets)) 

(vals (map cadr sets)) 

(temps (map (lambda (x) 

(generate-identifier)) 
sets))) 

'(.(syntax let) ,(map list temps vals) 

, @(map (lambda (id temp) 

'(,(syntax set! ) ,id ,temp)) 
ids 

temps) 

#f)>)))> 


(construct-identifier id symbol) procedure 

Creates and returns an identifier named by symbol that 
behaves as if it had been introduced where the identifier id 
was introduced. 
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Construct-identifier is used to circumvent hygiene by 
creating an identifier that behaves as though it had been 
implicitly present in some expression. For example, the 
transformer for a structure definition macro might con¬ 
struct the name of a field accessor that does not explic¬ 
itly appear in a use of the macro, but can be constructed 
from the names of the structure and the field. If a bind¬ 
ing for the field accessor were introduced by a hygienic 
transformer, then it would be renamed automatically, so 
that the introduced binding would fail to capture any ref¬ 
erences to the field accessor that were present in the input 
and were intended to be within the scope of the introduced 
binding. 

Another example is a macro that implicitly binds exit: 

(define-syntax loop-until-exit 
(lambda (x) 

(let ((exit (construct-identifier 

(car (unwrap-syntax x)) 

’exit)) 

(body (car (unwrap-syntax 

(cdr (unwrap-syntax x)))))) 

' (,(syntax call-with-current-continuation) 

(, (syntax lambda) 

(.exit) 

(.(syntax letrec) 

((,(syntax loop) 

(,(syntax lambda) () 

.body 

(.(syntax loop))))) 

(.(syntax loop)))))))) 


paper on his experience, pointing out that an implementa¬ 
tion based on syntactic closures must determine the syntac¬ 
tic roles of some identifiers before macro expansion based 
on textual pattern matching can make those roles appar¬ 
ent. William Clinger observed that Kohlbecker’s algorithm 
amounts to a technique for delaying this determination, 
and proposed a more efficient version of Kohlbecker’s algo¬ 
rithm. Pavel Curtis spoke up for referentially transparent 
local macros. Rees merged syntactic environments with 
the modified Kohlbecker’s algorithm and implemented it 
all, twice [13]. 

Dybvig and Hieb designed and implemented the low-level 
macro facility described above. Recently Hanson and Baw- 
den have extended syntactic closures to obtain an alterna¬ 
tive low-level macro facility. The macro committee has not 
endorsed any particular low-level facility, but does endorse 
the general concept of a low-level facility that is compati¬ 
ble with the high-level pattern language described in this 
appendix. 

Several other people have contributed by working on 
macros over the years. Hal Abelson contributed by holding 
this report hostage to the appendix on macros. 


(let ((x 0) (y 1000)) 
(loop-until-exit 
(if (positive? y) 

(begin (set! x (+ x 3)) 
(set! y (- y 1))) 
(exit x)))) => 3000 
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ALPHABETIC INDEX OF DEFINITIONS OF CONCEPTS, 
KEYWORDS, AND PROCEDURES 


The principal entry for each term, procedure, c 
listed first, separated from the other entries by 

! 4 

’ 7; 16 
* 21; 8, 38 

+ 21; 5, 8, 13, 19, 28, 36, 38 
, ll; 16 
- 21; 5, 38 
-> 4; 5 
... 5 

/ 21; 20, 38 
; 5 

< 21; 36, 38 
<= 21; 25, 38 
= 21; 14, 38 
=> 9 
> 21; 38 
>= 21; 38 
? 4 
' 12 

abs 21; 13, 23 
acos 23 
and 9; 13, 38 
angle 23 
append 17;38 
apply 27; 36 
approximate 38 
asin 23 
assoc 17 
assq 17 
assv 17 
at-sign 11 
at an 23 

#b 20; 32 

back quote 11 

begin 10; 11, 12, 37, 38 

binding 6 

binding construct 6 

boolean? 13;38 

bound 6 

bound-identifier=? 45 

caar 16 
caddr 16 
cadr 16 
call 8 

call by need 11 

call-with-current-continuation 28; 29,f 
call-with-input-file 29 
call-with-output-file 29 


keyword is call/cc 29 
semicolon. car 16; 7, 15, 36 
case 9;38 
catch. 29 
cdddar 16 
cddddr 16 
cdr 16; 15, 28 
ceiling 22 
char->integer 25 
char-alphabetic? 25 
char-ci<=? 25 
char-ci<? 25 
char-ci=? 25 
char-ci>=? 25 
char-ci>? 25 
char-downcase 25 
char-lower-case? 25 
char-numeric? 25 
char-ready 30 
char-ready? 30;31 
char-upcase 25 
char-upper-case? 25 
char-whitespace? 25 
char<=? 24; 25 
char<? 24; 26 
char=? 24;14,25 
char>=? 24 
char>? 24 
char? 24;38 
char->integer 25 
close-input-port 30 
close-output-port 30 
combination 8 
comma 11 
comment 5; 32 
complex? 20; 19, 21 
cond 9;13 
cons 16;15 

. " constant 7 

construct-identifier 45 
continuation 29 
cos 23 

current-input-port 30; 31 
current-output-port 30; 31 

#d 20 
d 20 

define 12;13 
define-syntax 41 
definition 12 
delay 11; 28 
denominator 22 



display 31 
do 11; 6, 13, 37, 38 
dotted pair 15 

#e 20; 32 
e 20 
else 9 

empty list 15; 16 

eof-object? 30 

eq? 15; 8, 13,17 

equal? 15;13, 17, 26 

equivalence predicate 13 

eqv? 13; 7, 8, 9, 14, 15, 16, 17, 18, 38 

error 3 

escape procedure 28 
essential 3 
even? 21 
exact 14 

exact->inexact 23 
exact? 21 
exact->inexact 23 
exactness 19 
exp 22 
expt 23 

#f 13; 20 
f 20 

false 6; 13 
floor 22 
foo 5; 12 
for-each 28; 38 
force 28;11, 38 
free-identifier=? 44 

gcd 22 

gen-counter 14 
gen-loser 14 
generate-identifier 45 

hygienic 40 

#i 20; 32 

identifier 5; 6, 18, 32 
identifier~>symbol 45 
identifier? 44 
if 8; 13, 35, 36 
imag-part 23 
immutable 7 

implementation restriction 4; 19 
improper list 16 
inexact 14 

inexact->exact 23; 19, 22 
inexact? 21 
inexact->exact 23 
initial environment 13 
input-port? 29 


integer->char 25; 38 
integer? 20;19 
integer->char 25 
integrate-system 39 
internal definition 13 

keyword 5; 6, 32, 40 

1 20 

lambda 8; 13, 34, 35, 36, 38 

lambda expression 6 

last-pair 38 

lazy evaluation 11 

lcm 22 

length 17;19 

let 10; 11, 6, 13, 37, 38 

let* 10;6,13 

let-syntax 41 

letrec 10;6, 13,38 

letrec-syntax 41 

list 17; 27 

list->string 26 

list->vector 27; 4 

list-ref 17 

list-tail 17 

list? 16;38 

list->string 26 

load 31 

location 7 

log 22; 23 

macro 40 
macro keyword 40 
macro transformer 40 
macro use 40 
magnitude 23 
make-polar 23 
make-promise 28 
make-rectangular 23 
make-string 25 
make-vector 26 
map 27; 28, 38, 39 
map-streams 39 
max 21 
member 17 
memq 17 
memv 17; 37 
min 21 
modulo 22 
mutable 7 

negative? 21 
newline 31 
nil 13; 38 
not 13 
null? 16 
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number 18 

number->string 23;38 
number? 20; 19,21, 38 
number->string 23; 24 
numerator 22 
numerical types 19 

#o 20; 32 
object 3 
odd? 21 

open-inputsile 30 
open-outputsile 30 
or 9; 13, 38 
output-port? 29 

pair 15 
pair? 16;38 
peek-char 30;38 
port 29 
positive? 21 
predicate 13 
procedure call 8 
procedure? 27;38 
promise 11; 28 

quasiquote 11;12,16,38 
quote 7; 6, 16 
quotient 22 

rational? 20; 19, 21 
rationalize 22; 38 
read 30; 3, 6, 16, 18, 33 
read-char 30 
real-part 23 
real? 20;19, 21 
referentially transparent 40 
region 6; 9, 10, 11 
remainder 22 
return 29 
reverse 17 
round 22 
runge-kutta-4 39 

s 20 

sequence 11 
set! 9; 12, 35, 36 
set-car! 16; 7, 15,36 
set-cdr! 16;15 
simplest rational 22 
sin 23 
sqrt 23; 20 
string 25 
string->list 26 
string->number 24; 38 
string->symbol 18 
string-append 26 


string-ci<=? 26 
string-ci<? 26 
string-ci=? 26 
string-ci>=? 26 
string-ci>? 26 
string-copy 26 
string-fill! 26 
string-length 25;19 
string-ref 25;7 
string-set! 26;7,18 
string<=? 26 
string<? 26 
string=? 26 
string>=? 26 
string>? 26 
string? 25; 38 
string->list 26 
string->symbol 18 
substring 26 
symbol->string 18; 7 
symbol? 18; 38 
symbol->string 18 
syntactic keyword 5; 6, 32, 40 
syntax 44 
syntax-rules 42 

#t 13; 38 
t 38 
tan 23 
token 32 

top level environment 13; 6 
transcript-off 31 
transcript-on 31 
true 6; 8, 9, 13 
truncate 22 
type 7 

unbound 6;7,12 
unquote 12; 16 
unquote-splicing 12; 16 
unspecified 4 
unwrap-syntax 44 

valid indexes 25; 26 
values-list 36 
variable 6; 5, 7, 32 
vector 27 
vector->list 27 
vector-fill! 27 
vector-length 27;19 
vector-ref 27;7 
vector-set! 27 
vector? 26;38 

whitespace 5 

with-input-from-file 30 
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with-output-to-file 30 
write 31; 6, 12,18 
write-char 31 

#x 20; 32 

zero? 21 
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Macros in Scheme 


William Clinger 


Although macros are even older than Lisp, Scheme has just become the first 
block-structured programming language to support a reliable macro system. 
This macro system is described in the appendix to the Revised 1 Report on the 
Algorithmic Language Scheme [1], This technical report contains three more 
articles on the subject of macros in Scheme, counting the article you are reading. 
I wrote this as an introduction to the other two articles, because it is very hard 
to understand their purpose without some further background on macros in 
Scheme. 

Macros are hardly new in the Lisp world, so I can explain what is new about 
the Scheme macro system by comparing it to Common Lisp’s [5]. Consider a 
simple push macro that is like the push macro in Common Lisp except that the 
place being pushed is required to be a variable. In Scheme we can write this 
macro as 

(deline-syntax push 
(syntax-rules () 

((push item place) 

(set! place (cons item place))))) 

and we can use push in an expression such as 

(let* ((cons (lambda (name) 

(case name 

((phil) ’("three-card monte")) 

((dick) ’("secret plan to end the war" 
"agnew" 

"not a crook")) 

((jimmy) ’("why not the best")) 

((ron) ’("abolish the draft" 

"balance the budget")) 

(else ’())))) 

(scams (cons ’phil))) 

(push (car (cons ’jimmy)) scams) 

(push (cadr (cons ’ron)) scams) 
scams) 

This expression will evaluate to 

("balance the budget" "why not the best" "three-card monte") 
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That, at least, is what this expression will evaluate to in Scheme. 

We’re not supposed to write expressions like this in Common Lisp, according 
to LISP-SYMBOL-REDEFINITION:MAR89-X3Ji3. (The “consequences are unde¬ 
fined”). One reason for this decision by X3J13 is that the Common Lisp macro 
system is unreliable, so a lexical binding of cons as in the above example can 
break macros such as push. The decision by X3J13 doesn’t really solve the prob¬ 
lem, because it doesn’t address macros that refer to global functions written by 
the user of a Common Lisp system, but it does make Common Lisp significantly 
less unreliable in practice. 

Recognizing that LISP-SYMBOL-REDEFINITION:MAR89-X3J13 doesn’t com¬ 
pletely solve the problem, let’s push forward with our example as though X3J13 
didn’t exist. (Otherwise I would have to construct a different example!) 

If we translate everything to pre-X3J 13 Common Lisp we will get an error, 
because in Common Lisp the first use of push would expand into 

(setq scams (cons (cons ’jimmy) scams)) 

within a context where cons is bound to a one-argument procedure. There are 
various ways one might try to work around this problem in Common Lisp, but 
none are fully general. If a macro needs to refer to a global variable or function 
(other than those predefined in the common-lisp package, which X3J13 has 
effectively made into reserved words), then it is quite impossible to write that 
macro reliably using the Common Lisp macro system. 

I’m as willing as anyone to pick on Common Lisp, but that’s not what I’m 
doing here. When Common Lisp was being designed Scheme had no macro 
system at all, for this very reason: Macros were inherently unreliable, or so 
we thought then. Even today, except for Scheme and a couple of research 
languages that employ a Scheme-style macro system, Common Lisp probably 
has the most sophisticated macros of any programming language. The fact is 
that macros have been unreliable in block-structured programming languages 
for thirty years, and that unreliability has just been accepted as the state of the 
art. 

How does Scheme’s new macro system manage to avoid this problem? In 
effect, the macro expander systematically renames local variables to avoid all 
inadvertent captures of bound variables, so the macro-expanded form of the 
expression above will be something like 

(let* ((cons.i (lambda (name) 

(case name 

((phil) ’("three-card monte")) 

((dick) ’("secret plan to end the war" 
"agnew" 

"not a crook")) 

((jimmy) ’("why not the best")) 

((ron) ’("abolish the draft" 
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"balance the budget")) 

(else ’())))) 

(scams (cons.l ’phil))) 

(set! scams (cons (car (cons.l ’jimmy)) scams)) 

(set! scams (cons (cadr (cons.l ’ron)) scams)) 
scams) 

A macro system that avoids inadvertent captures through systematic re¬ 
naming is said to be hygienic. Eugene Kohlbecker developed and implemented 
the first hygienic macro system for his 1986 PhD dissertation [4], In 1988 the 
Scheme community asked a four-person committee to design a hygienic macro 
system for inclusion in the Revised 4 Report. In 1990 Jonathan Rees and I 
developed a more general and efficient form of Kohlbecker’s algorithm, which 
Jonathan used to implement a prototype of the Scheme macro system [2]. 

The Revised 4 Report specifies the syntax and semantics of a hygienic macro 
system, but does not prescribe any particular algorithm. The Revised 4 Report 
does describe a non-hygienic, low-level macro facility that could be used to 
implement the hygienic macro system I have been describing, but goes on to 
note that this particular low-level facility “is but one of several low-level facilities 
that have been designed and implemented to complement” Scheme’s hygienic 
macro system. The following articles describe two more of them. 

Before moving on to the low-level facilities, I want to show you more of the 
power of Scheme’s hygienic macro system. First let us consider a simplified form 
of Common Lisp’s setf macro. With the Scheme macro system there are no 
reserved words, so we can redefine set ! locally as in 

(let-syntax 

((set! (syntax-rules (car cdr vector-ref) 

((set! (car x) y) (set-car! x y)) 

((set! (cdr x) y) (set-cdr! x y)) 

((set! (vector-ref x e) y) (vector-set! x e y)) 
((set! x y) (set! x y))))) 

(let* ((days (list ’monday ’Wednesday ’friday)) 

(dayi ’Sunday)) 

(set! (car days) ’tuesday) 

(set! dayl (car days)) 
dayl)) 

The (car cdr vector-ref) following syntax-rules means that car, cdr, and 
vector-ref are not pattern variables. They can match only themselves. The 
use of let-syntax instead of letrec-syntax means that the let-syntax macro 
is not recursive, so it can refer to the outer definition of set ! in the last rule 
without circularity. 

In Common Lisp, (setf (car days) ’tuesday) will not be expanded if 
it occurs within a local binding for car. (At least that is so according to 
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FUNCTION-NAME:SMALL. On the other hand, the consequences are supposed 
to be undefined if car is bound locally. Perhaps some Common Lisp wizard can 
explain this to me.) The purpose of this rule in Common Lisp is to ensure that 
the scope of a setf method that is associated with a function does not exceed 
the scope of the function itself. 

This limitation of the scope of a set ! method will be enforced automatically 
by the Scheme macro system, because the car in the pattern will match a car in 
a use only if the two occurrences of car are within the scope of the same binding 
of car. Since this scope is lexical (whether local or global), the Scheme macro 
system generalizes Common Lisp’s rule for setf in the way that is appropriate 
for block-structured languages like Scheme. 

Of course, none of this is special to setf. Scheme’s hygienic macro system 
is a general mechanism for defining syntactic transformations that reliably obey 
the rules of lexical scope. 

Another (rather silly) example might help to make the point: 


(let ((car cdr) 

(set-car! set-cdr!) 

(cdr car) 

(set-cdr! set-car!)) 

(let-syntax 

((set! (syntax-rules (car cdr vector-ref) 

((set! (car x) y) (set-car! x y)) 

((set! (cdr x) y) (set-cdr! x y)) 

((set! (vector-ref x e) y) (vector-set! x e y)) 
((set! x y) (set! x y))))) 

(let ((days (list ’monday ’Wednesday ’friday)) 

(set-car! (lambda () 17))) 

(set! (car days) ’tuesday) 

(cons (set-car!) days)))) 


In Scheme this evaluates to (17 monday . tuesday). This is easy to see if 
you forget everything you thought you knew about macros, and rely only on the 
fact that all (non-pattern-variable) identifiers in the macro definition, whether 
they occur on the left or on the right hand side of a syntax rule, are resolved 
using Scheme’s familiar lexical scope rules. 

Alas, I cannot easily implement an analogue of Common Lisp’s setf in 
Scheme using the high-level macro system. Although local macros can be either 
recursive (letrec-syntax) or non-recursive (let-syntax), global macros are 
always recursive (def ine-syntax). This should be fixed. 

Another problem with macros in Scheme is that some macros are awkward 
or impossible to describe using the pattern language. Suppose we want to define 
a set* ! macro to perform assignments in parallel, with 

(set*! il ei i2 e2 .. .) 
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expanding into 

(let ((tl el) (t2 e2) ...) 

(set! il tl) 

(set! i2 t2) 

...) 

This is hard to express for two reasons. The first is that the variables to be 
assigned need to be paired up with the expressions giving their new values. 
The second difficulty is that the macro must generate an indefinite number of 
temporary variables. 

The set*! macro can be defined using an auxiliary macro to perform the 
pairing and to generate the temporaries. Although it might appear that the 
same temporary is being used for each assignment, the hygienic macro system 
automatically renames each binding occurrence that is inserted by a macro, 
together with all occurrences within its scope. Since each temporary that is 
inserted by the auxiliary macro eventually becomes a binding occurrence, each 
will be renamed. (Amazing but true.) 

(define-syntax set*! 

(syntax-rules () 

((set*! il el more ...) 

(set*!-aux () il el more ...)))) 

(deline-syntax set*!-aux 
(syntax-rules () 

((set*!-aux ((il el tl) ...)) 

(let ((tl el) ...) 

(set! il tl) ...)) 

((set*!-aux ((il el tl) ...) i2 e2 more ...) 

(set*!-aux ((il el tl) ... (i2 e2 newtemp)) more ...)))) 

This definition of set*! may be compared with the set* ! macro that is defined 
in the Revised 4 Report using the low-level macro system. Although set*! was 
put forth as an example of a macro that would be easier to write in a low-level 
macro system, I prefer the high-level definition above. 

This definition would be more elegant if the auxiliary macro were local to 
each use of set*! . That would be less efficient because the auxiliary macro 
would have to be re-compiled for each use, but the real reason I didn’t use a 
local macro is that I can’t express the macro I want using syntax-rules! 

The problem is annoyingly syntactic: If I tried to use syntax-rules to say 
that set*! expands into a letrec-syntax that defines set*!-aux, then the 
seven ellipses that appear in the definition of set*!-aux would appear on the 
right hand side of the syntax rule for set*!. The macro expander would try 
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to expand these seven ellipses when transcribing the use of set*!, just as it 
expands the one ellipsis that appears on the right hand side of the syntax rule 
for set*! above. Somehow the macro expander needs to know to expand that 
one ellipsis, while waiting until the local macro is used to expand the other 
seven ellipses. A similar problem is solved in TjcX by an escape character, and 
this solution should work in Scheme as well. 

The low-level system described in the Revised 4 Report uses syntax as an 
escape character. Some such mechanism needs to be added to the high-level 
system. 

Despite these problems, syntax-rules with recursion is reasonably expres¬ 
sive. It can express all recursive functions on lists, where cons, car, cdr, null?, 
and equal? on non-list elements are the base functions. The pattern language 
cannot do much with non-lists, however. It cannot take the successor of a nu¬ 
meral, for example. 

The primary limitation of the hygienic macro system is that it is thoroughly 
hygienic, and thus cannot express macros that bind identifiers implicitly. Com¬ 
mon Lisp’s def struct is an example of a non-hygienic macro, since it implicitly 
defines accessor functions for the structure. The loop-until-exit macro that 
is used as an example of the low-level macro system in the Revised 4 Report is 
also a non-hygienic macro. It may usefully be compared with similar macros in 
the following articles. 

In conclusion, the hygienic macro system described in the Revised 4 Report is 
a considerable advance over previous macro systems. It has a few bugs yet, for 
which solutions can easily be imagined. Even if these bugs are fixed, however, 
there will still be non-hygienic macros and perhaps even a few hygienic macros 
that cannot be written using the hygienic macro system. That is why the 
Revised 4 Report also describes a compatible low-level macro system. 

The low-level macro system described in the Revised 4 Report is experimen¬ 
tal, and is likely to evolve considerably or be replaced altogether. Two alter¬ 
native low-level macro systems are described in the following articles, and I am 
sure that even more will be designed during the next few years. 

Scheme’s hygienic macro system uses a stable technology, and Scheme pro¬ 
grammers can use it to define most macros in a portable way. I am sure that the 
hygienic macro system will be extended, but I do not expect it to change very 
much. The hygienic macro system should certainly be considered for inclusion 
when the IEEE standard for Scheme [3] is next revised. 

The low-level macro facilities provide an escape for those few macros that 
cannot be written using the hygienic macro system, but macros written using the 
low-level facilities will not be portable until the Scheme community has gained 
enough experience with these low-level macro systems to design and adopt one 
low-level system as an informal standard. 
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A Syntactic Closures Macro Facility 

by Chris Hanson 
9 November 1991 


This document describes syntactic closures, a low-level macro facility for the Scheme program¬ 
ming language. The facility is an alternative to the low-level macro facility described in the Re¬ 
vised'' 4 Report on Scheme. This document is an addendum to that report. 

The syntactic closures facility extends the bnf rule for transformer spec> to allow a new 
keyword that introduces a low-level macro transformer: 

transformer spec> >-»• (transformer <expression>) 

Additionally the following procedures are added: 

make-syntactic-closure 

capture-syntactic-environment 

identifier? 

identifier*? 


The description of the facility is divided into three parts. The first part defines basic terminology. 
The second part describes how macro transformers are defined. The third part describes the use 
of identifiers , -which extend the syntactic closure mechanism to be compatible with syntax-rules. 


Terminology 


This section defines the concepts and data types used by the syntactic closures facility. 

• Forms are the syntactic entities out of which programs are recursively constructed. A form is 
any expression, any definition, any syntactic keyword, or any syntactic closure. The variable 
name that appears in a set! special form is also a form. Examples of forms: 
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#t 

car 

(+ x 4) 

(lambda (x) x) 

(define pi 3.14159) 
if 

define 

• An alias is an alternate name for a given symbol. It can appear anywhere in a form that the 
symbol could be used, and when quoted it is replaced by the symbol; however, it does not 
satisfy the predicate symbol?. Macro transformers rarely distinguish symbols from aliases, 
referring to both as identifiers. 

• A syntactic environment maps identifiers to their meanings. More precisely, it determines 
whether an identifier is a syntactic keyword or a variable. If it is a keyword, the meaning is 
an interpretation for the form in which that keyword appears. If it is a variable, the meaning 
identifies which binding of that variable is referenced. In short, syntactic environments contain 
all of the contextual information necessary for interpreting the meaning of a particular form. 

• A syntactic closure consists of a form, a syntactic environment, and a list of identifiers. All 
identifiers in the form take their meaning from the syntactic environment, except those in the 
given list. The identifiers in the list are to have their meanings determined later. 

A syntactic closure may be used in any context in which its form could have been used. Since 
a syntactic closure is also a form, it may not be used in contexts where a form would be illegal. 
For example, a form may not appear as a clause in the cond special form. 

A syntactic closure appearing in a quoted structure is replaced by its form. 


Transformer Definition 

This section describes the transformer special form and the procedures make-syntactic- 
closure and capture-syntactic-environment. 


transformer expression syntax 

Syntax: It is an error if this syntax occurs except as a Ctransformer spec>. 

Semantics: The expression is evaluated in the standard transformer environment to 
yield a macro transformer as described below. This macro transformer is bound to a 
macro keyword by the special form in which the transformer expression appears (for 
example, let-syntax). 


A macro transformer is a procedure that takes two arguments, a form and a syntactic 
environment, and returns a new form. The first argument, the input form, is the form 
in which the macro keyword occurred. The second argument, the usage environment, 
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is tlie syntactic environment in which the input form occurred. The result of the 
transformer, the output form, is automatically closed in the transformer environment, 
which is the syntactic environment in which the transformer expression occurred. 

For example, here is a definition of a push macro using syntax-rules: 


(define-syntax push 
(syntax-rules 0 
((push item list) 

(set! list (cons item list))))) 


Here is an equivalent definition using transformer: 


(define-syntax push 
(transformer 
(lambda (exp env) 

(let ((item 

(make-syntactic-closure env ’ () (cadr exp))) 
(list 

(make-syntactic-closure env ’() (caddr exp)))) 
‘(set! .list (cons .item .list)))))) 


In this example, the identifiers set! and cons are closed in the transformer environ¬ 
ment, and thus will not be affected by the meanings of those identifiers in the usage 
environment env. 


Some macros may be non-hygienic by design. For example, the following defines a 
loop macro that implicitly binds exit to an escape procedure. The binding of exit is 
intended to capture free references to exit in the body of the loop, so exit must be 
left free when the body is closed: 


(define-syntax loop 
(transformer 
(lambda (exp env) 

(let ((body (cdr exp))) 

*(call-with-current-continuation 
(lambda (exit) 

(let f () 

,@(map (lambda (exp) 

(make-syntactic-closure env ’(exit) 
exp)) 
body) 

(f)))))))) 
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To assign meanings to the identifiers in a form, use make-syntactic-closure to close the form 
in a syntactic environment. 


make-syntactic-closure environment free-names form procedure 

Environment must be a syntactic environment, free-names must be a list of identifiers, 
and form must be a form, make-syntactic-closure constructs and returns a syntactic 
closure of form in environment, which can be used anywhere that form could have been 
used. All the identifiers used in form, except those explicitly excepted by free-names, 
obtain their meanings from environment. 


Here is an example where free-names is something other than the empty list. It is 
instructive to compare the use of free-names in this example with its use in the loop 
example above: the examples are similar except for the source of the identifier being 
left free. 


(define-syntax letl 
(transformer 
(lambda (exp env) 

(let ((id (cadr exp)) 

(init (caddr exp)) 

(exp (cadddr exp))) 

‘((lambda (,id) 

,(make-syntactic-closure env (list id) exp)) 
,(make-syntactic-closure env ’() init)))))) 


letl is a simplified version of let that only binds a single identifier, and whose body 
consists of a single expression. When the body expression is syntactically closed in its 
original syntactic environment, the identifier that is to be bound by letl must be left 
free, so that it can be properly captured by the lambda in the output form. 


To obtain a syntactic environment other than the usage environment, use capture-syntactic- 
environment. 

capture-syntactic-environment procedure procedure 

capture-syntactic-environment returns a form that will, when transformed, call 
procedure on the current syntactic environment. Procedure should compute and return 
a new form to be transformed, in that same syntactic environment, in place of the form. 

An example will make this clear. Suppose we wanted to define a simple loop-until 
keyword equivalent to 
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(define-syntax loop-until 
(syntax-rules () 

((loop-until id init test return step) 
(letrec ((loop 

(lambda (id) 

(if test return (loop step))))) 
(loop init))))) 


The following attempt at defining loop-until has a subtle bug: 


(define-syntax loop-until 
(transformer 
(lambda (exp env) 

(let ((id (cadr exp)) 

(init (caddr exp)) 

(test (cadddr exp)) 

(return (cadddr (cdr exp))) 

(step (cadddr (cddr exp))) 

(close 

(lambda (exp free) 

(make-syntactic-closure env free exp)))) 
‘(letrec ((loop 

(lambda (,id) 

(if ,(close test (list id)) 

.(close return (list id)) 

(loop .(close step (list id))))))) 
(loop .(close init ’()))))))) 


This definition appears to take all of the proper precautions to prevent unintended 
captures. It carefully closes the subexpressions in their original syntactic environment 
and it leaves the id identifier free in the test, return, and step expressions, so that 
it will be captured by the binding introduced by the lambda expression. Unfortunately 
it uses the identifiers if and loop within that lambda expression, so if the user of 
loop-until just happens to use, say, if for the identifier, it will be inadvertently 
captured. 


The syntactic environment that if and loop want to be exposed to is the one just out¬ 
side the lambda expression: before the user’s identifier is added to the syntactic environ¬ 
ment, but after the identifier loop has been added, capture-syntactic-environment 
captures exactly that environment as follows: 



6 


Re vised "4 Scheme 


(define-syntax loop-until 
(transformer 
(lambda (exp env) 

(let ((id (cadr exp)) 

(init (caddr exp)) 

(test (cadddr exp)) 

(return (cadddr (cdr exp))) 

(step (cadddr (cddr exp))) 

(close 

(lambda (exp free) 

(make-syntactic-closure env free exp)))) 

‘(letrec ((loop 

,(capture-syntactic-environment 
(lambda (env) 

‘(lambda (,id) 

(,(make-syntactic-closure env ’() ‘if) 
.(close test (list id)) 

.(close return (list id)) 
(.(make-syntactic-closure env ’() ‘loop) 
.(close step (list id))))))))) 

(loop .(close init ’()))))))) 


In this case, having captured the desired syntactic environment, it is convenient to 
construct syntactic closures of the identifiers if and the loop and use them in the 
body of the lambda. 


A common use of capture-syntactic-environment is to get the transformer environ¬ 
ment of a macro transformer: 


(transformer 
(lambda (exp env) 

(capture-syntactic-environment 
(lambda (transformer-env) 
...)))) 


Identifiers 

This section describes the procedures that create and manipulate identifiers. Previous syntactic 
closure proposals did not have an identifier data type—they just used symbols. The identifier data 
type extends the syntactic closures facility to be compatible with the high-level syntax-rules 
facility. 

As discussed earlier, an identifier is either a symbol or an alias. An alias is implemented as a 
syntactic closure whose form is an identifier: 
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(make-syntactic-closure env ’() ’a) => an alias 

Aliases are implemented as syntactic closures because they behave just like syntactic closures most 
of the time. The difference is that an alias may be bound to a new value (for example by lambda or 
let-syntax); other syntactic closures may not be used this way. If an alias is bound, then within 
the scope of that binding it is looked up in the syntactic environment just like any other identifier. 

Aliases are used in the implementation of the high-level facility syntax-rules. A macro trans¬ 
former created by syntax-rules uses a template to generate its output form, substituting subforms 
of the input form into the template. In a syntactic closures implementation, all of the symbols in 
the template are replaced by aliases closed in the transformer environment, while the output form 
itself is closed in the usage environment. This guarantees that the macro transformation is hygienic, 
without requiring the transformer to know the syntactic roles of the substituted input subforms. 


identifier? object procedure 

Returns #t if object is an identifier, otherwise returns #f. Examples: 


(identifier? ’a) => #t 

(identifier? (make-syntactic-closure env ’() ’a)) 

=» #t 

(identifier? "a") #f 

(identifier? #\a) => #f 

(identifier? 97) => #f 

(identifier? #f) => #f 

(identifier? ’(a)) => #f 

(identifier? ’#(a)) => #f 


The predicate eq? is used to determine if two identifers are “the same”. Thus eq? can be used 
to compare identifiers exactly as it would be used to compare symbols. Often, though, it is useful to 
know whether two identifiers “mean the same thing”. For example, the cond macro uses the symbol 
else to identify the final clause in the conditional. A macro transformer for cond cannot just look 
for the symbol else, because the cond form might be the output of another macro transformer that 
replaced the symbol else with an alias. Instead the transformer must look for an identifier that 
“means the same thing” in the usage environment as the symbol else means in the transformer 
environment. 


identifier^? environmentl identifierl environment2 identified procedure 

Environment! and environment? must be syntactic environments, and identifierl and 
identified must be identifiers, identifier? returns #t if the meaning of identifierl 
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in environmentl is the same as that of identifier‘2 in environment2, otherwise it returns 
#f. Examples: 


(let-syntax 

((foo 

(transformer 
(lambda (form env) 

(capture-syntactic-environment 
(lambda (transformer-env) 

(identifier=? transformer-env ’x env ’x))))))) 
(list (foo) 

(let ((x 3)) 

(foo)))) 

=> (#t #f) 


(let-syntax ((bar foo)) 

(let-syntax 

((foo 

(transformer 
(lambda (form env) 

(capture-syntactic-environment 
(lambda (transformer-env) 

(identifier=? transformer-env ’foo 

env (cadr form)))))))) 

(list (foo foo) 

(foo bar)))) 

=> (#f #t) 
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Hygienic Macros Through Explicit Renaming 


William Clinger 


This paper describes an alternative to the low-level macro facility described 
in the Revised 1 Report on the Algorithmic Language Scheme [1], The facility 
described here is based on explicit renaming of identifiers, and was developed for 
the first implementation of the hygienic macro expansion algorithm described 
in [2], It was the first low-level macro facility to be designed for compatibility 
with a high-level hygienic macro system, and it remains one of the easiest to 
understand. 

Whereas the low-level macro facility described in the Revised 4 Report re¬ 
names identifiers automatically, so that hygienic macros are obtained by default, 
the facility described here requires that identifiers be renamed explicitly in order 
to maintain hygiene. 

Another difference is that, as originally implemented and as described here, 
there is no way to define certain hygienic macros that define other hygienic 
macros. The problem is that the transformation procedure for the defined macro 
may need to compare pieces of its first argument with the denotation of an 
identifier, but the only way for the defining macro to pass that denotation along 
to the defined macro is as part of the code for the defined macro. This problem 
can be solved by introducing syntax expressions as in the Revised 4 Report. 
Syntax is like quote, except that the denotation of an identifier quoted by 
syntax is preserved as part of the quoted value. 

As with the low-level macro facility based on syntactic closures [3], the ex¬ 
plicit renaming facility adds a new production for {transformer spec): 


(transformer) —► (transformer (expression)) 

The (expression) is expanded in the syntactic environment of the transformer 
expression, and the expanded expression is evaluated in the standard trans¬ 
former environment to yield a transformation procedure. The transformation 
procedure takes an expression and two other arguments and returns a trans¬ 
formed expression. For example, the transformation procedure for a call macro 
such that (call proc arg .. .) expands into ( proc arg ...) can be written 
as 


(lambda (exp rename compare) 
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(cdr exp)) 

Expressions are represented as lists in the traditional manner, except that iden¬ 
tifiers may be represented by objects other than symbols. Transformation pro¬ 
cedures may use the predicate identifier? to determine whether an object is 
the representation of an identifier. 

The second argument to a transformation procedure is a renaming procedure 
that takes the representation of an identifier as its argument and returns the 
representation of a fresh identifier that occurs nowhere else in the program. For 
example, the transformation procedure for a simplified version of the let macro 
might be written as 

(lambda (exp rename compare) 

(let ((vars (map car (cadr exp))) 

(inits (map cadr (cadr exp))) 

(body (cddr exp))) 

‘((lambda ,vars ,©body) 

,©inits))) 

This would not be hygienic, however. A hygienic let macro must rename the 
identifier lambda to protect it from being captured by a local binding. The re¬ 
naming effectively creates an fresh alias for lambda, one that cannot be captured 
by any subsequent binding: 

(lambda (exp rename compare) 

(let ((vars (map car (cadr exp))) 

(inits (map cadr (cadr exp))) 

(body (cddr exp))) 

‘((.(rename ’lambda) ,vars .©body) 

,©inits))) 

The expression returned by the transformation procedure will be expanded in 
the syntactic environment obtained from the syntactic environment of the macro 
application by binding any fresh identifiers generated by the renaming procedure 
to the denotations of the original identifiers in the syntactic environment in 
which the macro was defined. This means that a renamed identifier will denote 
the same thing as the original identifier unless the transformation procedure 
that renamed the identifier placed an occurrence of it in a binding position. 

The renaming procedure acts as a mathematical function in the sense that 
the identifiers obtained from any two calls with the same argument will be the 
same in the sense of eqv?. It is an error if the renaming procedure is called after 
the transformation procedure has returned. 

The third argument to a transformation procedure is a comparison predicate 
that takes the representations of two identifiers as its arguments and returns 
true if and only if they denote the same thing in the syntactic environment 
that will be used to expand the transformed macro application. For example, 
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the transformation procedure for a simplified version of the cond macro can be 
written as 

(lambda (exp rename compare) 

(let ((clauses (cdr exp))) 

(if (null? clauses) 

‘(.(rename ’quote) unspecified) 

(let* ((first (car clauses)) 

(rest (cdr clauses)) 

(test (car first))) 

(cond ((and (identifier? test) 

(compare test (rename ’else))) 
‘(.(rename ’begin) ,®(cdr first))) 

(else '(.(rename ’if) 

.test 

(.(rename ’begin) ,®(cdr first)) 
(cond ,®rest)))))))) 

In this example the identifier else is renamed before being passed to the com¬ 
parison predicate, so the comparison will be true if and only if the test expression 
is an identifier that denotes the same thing in the syntactic environment of the 
expression being transformed as else denotes in the syntactic environment in 
which the cond macro was defined. If else were not renamed before being 
passed to the comparison predicate, then it would match a local variable that 
happened to be named else, and the macro would not be hygienic. 

Some macros are non-hygienic by design. For example, the following defines 
a loop macro that implicitly binds exit to an escape procedure. The binding 
of exit is intended to capture free references to exit in the body of the loop, 
so exit is not renamed. 

(define-syntax loop 
(transformer 
(lambda (x r c) 

(let ((body (cdr x))) 

'(,(r ’call-with-current-continuation) 

(,(r ’lambda) (exit) 

(,(r ’let) ,(r ’f) () .©body (,(r ’f))))))))) 

Suppose a while macro is implemented using loop, with the intent that 
exit may be used to escape from the while loop. The while macro cannot be 
written as 

(define-syntax while 
(syntax-rules () 

((while test body ...) 

(loop (if (not test) (exit #f)) 
body ...)))) 
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because the reference to exit that is inserted by the while macro is intended 
to be captured by the binding of exit that will be inserted by the loop macro. 
In other words, this while macro is not hygienic. Like loop, it must be written 
using the transformer syntax: 

(define-syntax while 
(transformer 
(lambda (x r c) 

(let ((test (cadr x)) 

(body (cddr x))) 

‘(,(r ’loop) 

(,(r ’if) (,(r ’not) .test) (exit #f)) 

,®body))))) 
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